Migration from MS VSS to Subversion

[Robert Graf-Waczenski <rg...@lsoft.com>]

Hi list,

i have been assigned the task of researching the feasibility of migrating
our nontrivial MS VSS repository to Subversion.

We have been using VSS for almost seven years now and the repository appears
stable and consistent but has grown beyond 7 GB now mostly due to our habit
of creating branches with physical repository copies which are of course
*not* cheap and therefore occupy lots of physical space - one major reason
to think about migrating to svn.

Our VSS repository looks like this:

$-comp1
`-comp2
`-comp3
  `-100-Docs
  `-200-Code
  `-V2.0
    `-100-Code
    `-200-Code
  `-V2.1
    `-100-Code
    `-200-Code

So each component has "Vwhatever" subfolders that contain the expensively
copied branches that were created a considerable amount of time ago.

I would like to transform this structure to a better one in subversion, i.e.
the suggested layout with the usual subfolders "trunk", "branches" and
"tags", but each living below the component's main folder, similar to this
here:

$-comp1
`-comp2
`-comp3
  `-trunk
    `-100-Docs
    `-200-Code
  `-branches
    `-V2.0
      `-100-Docs
      `-200-Code


The currently available migration tools create a dump file that i can import
to subversion, potentially piped and filtered via svndumpfilter.

Is there any chance to achieve the structure sketched above (with the
"trunk" and "branches" subfolders below each component's own folder and with
branches created as correct svn cheap copies) and still have the same
history information that we have in VSS?

Or do we have to create the subversion repository in a folder structure that
is initially identical to what we had in VSS and then move stuff around?

Thanks,

Robert

Re: Migration from MS VSS to Subversion

[Kenneth Porter <sh...@sewingwitch.com>]

On Wednesday, September 13, 2006 1:37 PM -0400 Kevin Greiner 
<gr...@gmail.com> wrote:

> That's the key question and I don't know the answer. You should ask the
> authors of the "currently available migration tools" or test for
> yourself.

<http://www.pumacode.org/projects/vss2svn>

One limitation of the converter is that it doesn't handle restore 
operations correctly. I'm investigating how to implement enough of this to 
make it work with my VSS DB.

> Probably easiest to just re-create the VSS layout and then move stuff
> around. After, they will be cheap copies.

That's the approach I plan to take.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Migration from MS VSS to Subversion

[Kevin Greiner <gr...@gmail.com>]

On 9/13/06, Robert Graf-Waczenski <rg...@lsoft.com> wrote:
>
>
> Is there any chance to achieve the structure sketched above (with the
> "trunk" and "branches" subfolders below each component's own folder and with
> branches created as correct svn cheap copies) and still have the same
> history information that we have in VSS?
>

That's the key question and I don't know the answer. You should ask the
authors of the "currently available migration tools" or test for yourself.

Or do we have to create the subversion repository in a folder structure that
> is initially identical to what we had in VSS and then move stuff around?
>

Probably easiest to just re-create the VSS layout and then move stuff
around. After, they will be cheap copies.

Re: Migration from MS VSS to Subversion

[Toby Johnson <to...@etjohnson.us>]

Robert Graf-Waczenski wrote:
> The currently available migration tools create a dump file that i can 
> import to subversion, potentially piped and filtered via svndumpfilter.
>  
> Is there any chance to achieve the structure sketched above (with the 
> "trunk" and "branches" subfolders below each component's own folder 
> and with branches created as correct svn cheap copies) and still have 
> the same history information that we have in VSS?

I'm not sure if you're referring to vss2svn with "currently available 
migration tools", but vss2svn will correctly translate a VSS "branch" 
action into a SVN cheap copy operation. So if you need to maintain 
history then I would suggest importing the whole thing to SVN as is, 
then moving stuff around afterwards, either manually or using a script 
as mentioned by others.

However, whenever there is a situation such as this that requires such 
deep restructuring of your repository, my advice is always to simply 
start fresh. Export all your stuff out of VSS, arrange it how you want, 
then import it to SVN as one step and start from there. Either keep your 
VSS repo around as read-only for reference, or if you want to remove VSS 
completely from your computers (and who doesn't?), convert that to a 
separate, read-only SVN repo that you can use for lookups. After a short 
while, you probably won't even need it at all anymore.

If you have more specific questions regarding vss2svn, there is a 
separate mailing list; see:
<http://www.pumacode.org/projects/vss2svn>

toby

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Migration from MS VSS to Subversion

[Blair Zajac <bl...@orcaware.com>]

On Sep 13, 2006, at 8:21 PM, Gavin Lambert wrote:

> Quoth Robert Graf-Waczenski <ma...@lsoft.com>:
>> We have been using VSS for almost seven years now and the repository
>> appears stable and consistent but has grown beyond 7 GB now mostly
>> due to our habit of creating branches with physical repository copies
>> which are of course *not* cheap and therefore occupy lots of physical
>> space - one major reason to think about migrating to svn.
> [...]
>> The currently available migration tools create a dump file that i can
>> import to subversion, potentially piped and filtered via
>> svndumpfilter.
>>
>> Is there any chance to achieve the structure sketched above (with the
>> "trunk" and "branches" subfolders below each component's own folder
>> and with branches created as correct svn cheap copies) and still have
>> the same history information that we have in VSS?
>>
>> Or do we have to create the subversion repository in a folder
>> structure that is initially identical to what we had in VSS and then
>> move stuff around?
>
> Unless you write something that'll manipulate the dump file for  
> you, any
> migration tool will most likely produce a dump that contains expensive
> copies, same as your original VSS repository.  (VSS doesn't know the
> difference, so it can't tell the migration tool.)
>
> So if you really want the history and branches retained (and you don't
> feel comfortable writing your own migration logic to tweak the dump
> file), then you'll need to manually set up your v1 structure, import
> that, then copy over to a branch, replace with v2 code, commit,  
> copy to
> branch, etc.  Fairly time consuming and error prone, I'd imagine.

You can use svn_load_dirs.pl to make that process much easier.  It  
even helps you track renames of files and directories in the v 
{1,2,...} into the Subversion repository.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Migration from MS VSS to Subversion

[Gavin Lambert <ga...@compacsort.com>]

Quoth Robert Graf-Waczenski <ma...@lsoft.com>:
> Writing something is of course an option, using Java or Perl
> or whatever. Would it be possible to modify the paths in the
> dumpfile, e.g. replace /comp1/ with /comp1/trunk/? (I did not
> yet even dare to try to open the dumpfile with an editor as
> it is of size 10 GB)
> 
> If i then load the dumpfile, would this give me what i want,
> i.e. repo folders /comp1/trunk/100-Docs,
> /comp1/trunk/200-Code with all old VSS history mirrored?

As long as you catch all the paths, then yes, it should work.

Be *VERY* careful when editing the dump though, and definitely do not
trust editors (even if you can find one that can open such a big file).
The dump file contains a mix of binary and text data, and some
editors/tools can't resist the urge to change some line endings around,
which will horribly break the file.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Migration from MS VSS to Subversion

[Robert Graf-Waczenski <rg...@lsoft.com>]

> Unless you write something that'll manipulate the dump file for you, any
> migration tool will most likely produce a dump that contains expensive
> copies, same as your original VSS repository.  (VSS doesn't know the
> difference, so it can't tell the migration tool.)

Writing something is of course an option, using Java or Perl or whatever.
Would it be possible to modify the paths in the dumpfile, e.g. replace
/comp1/ with /comp1/trunk/? (I did not yet even dare to try to open the
dumpfile with an editor as it is of size 10 GB)

If i then load the dumpfile, would this give me what i want, i.e. repo
folders /comp1/trunk/100-Docs, /comp1/trunk/200-Code with all old VSS
history mirrored?

I already have said goodbye to the old "Vwhatever" branches and will go
for a clean slate start with yet-to-be-created new branches in the future,
but capturing the old VSS history for the compX/trunk folders is crucial.

Robert

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Migration from MS VSS to Subversion

[Gavin Lambert <ga...@compacsort.com>]

Quoth Robert Graf-Waczenski <ma...@lsoft.com>:
> We have been using VSS for almost seven years now and the repository
> appears stable and consistent but has grown beyond 7 GB now mostly
> due to our habit of creating branches with physical repository copies
> which are of course *not* cheap and therefore occupy lots of physical
> space - one major reason to think about migrating to svn.    
[...]
> The currently available migration tools create a dump file that i can
> import to subversion, potentially piped and filtered via
> svndumpfilter.  
> 
> Is there any chance to achieve the structure sketched above (with the
> "trunk" and "branches" subfolders below each component's own folder
> and with branches created as correct svn cheap copies) and still have
> the same history information that we have in VSS?   
> 
> Or do we have to create the subversion repository in a folder
> structure that is initially identical to what we had in VSS and then
> move stuff around?  

Unless you write something that'll manipulate the dump file for you, any
migration tool will most likely produce a dump that contains expensive
copies, same as your original VSS repository.  (VSS doesn't know the
difference, so it can't tell the migration tool.)

So if you really want the history and branches retained (and you don't
feel comfortable writing your own migration logic to tweak the dump
file), then you'll need to manually set up your v1 structure, import
that, then copy over to a branch, replace with v2 code, commit, copy to
branch, etc.  Fairly time consuming and error prone, I'd imagine.

When we switched to Subversion we essentially just stuck a peg in the
sand, and imported only the current revision of the source.  So now we
can only look up to a certain point in the SVN history; beyond that we
have to fire up VSS and look at the history in there instead.  But we
haven't needed to do that very often, so it wasn't much of a hardship.
It also provided us the opportunity to refrain from importing some of
the accompanying cruft (old projects and experimental stuff) from the
old server :)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org