Subversion to Plastic migration questions

[alextxm]

Hello,

i'm evaluating Plastic SCM in order to replace our current subversion setup; as such i'm doing some tests on repositories migration capabilities. Unfortunately, most of our current svn repos are structured as multiple-products-per-repository, leading to paths like:

/repo/producta/trunk

/repo/producta/branches

/repo/producta/tags

/repo/productb/trunk

/repo/productb/branches

/repo/productb/tags

... (and so on) ...

which I noticed is not optimal for migration.

question #1:

It seems to me the best way to convert them is to split each product to a plastic-repository in the migration tool; am I correct? Is there a better way to handle such configuration?

question #2:

We have another complication in our current structure; please consider the following:

at revision, say, #10 we have:

/repo/folder1/name

...

/repo/folder2/anotherName

...

(name and anotherName are projects which do not have the trunk/branches/tags folder hierarchy)

then, at revision, say, #987, folder1 and folder2 had been merged into folder1 resulting in:

/repo/folder1/name

/repo/folder1/anotherName

...

Is there a way to import the whole changesets history of "name" and "anotherName" (across the folder1/folder2 change) into a single Plastic repository ?

Thank you in advance for your help,

Alessandro

[Guest]

Hello, alextxm:

First of all, thank you very much for choosing Plastic SCM, I think that it is a good idea to make SVN redundant in your company in any case!

Regarding your question, please, take a look here (http://www.plasticscm.com/releases/3.0.1/manuals-html/en/importersguide.htm) to know about Known issues of our SVN importer if you have not checked it yet.

Now, let's try to answer your questions:

#1)

What I recommend to you is to import every productX in a different Plastic SCM repository. To do that, you can specify "productX" as base and then specify trunk, branches and tags the subdirectories of that productX, as usual. This way you will have each project in a different repository, which is the solution we suggest to our customers.

#2)

As we state in the Known issues quoted above, we don't support non-standard hierarchies. To workaround this problem I suggest you to import from SVN to Plastic SCM establishing "repo" as base, "folder1" as trunk and "folder2" as branches. This is ok in case that you only have two folders (folder1 and folder2), like in the given example. Otherwise you will have to decide which structure you want to import as trunk, branches and tags. The reason why we do not support non-standard structures is because it is impossible to tell the importer what is the correct structure of the repository; therefore it is necessary to 'map' the actual structure to the standard structure.

Summarizing:

You can specify whatever location as trunk, branches and tags. If your repository follows the standard structure this step is straight forward; otherwise you will have to decide which location state as 'trunk', which one as 'branches' and which one as 'tags'.

Thanks again and do not hesitate to contact us if you have any other question. I hope you enjoy Plastic SCM.

Luis

[alextxm]

Luis,

thank you for your help

About my questions:

#1: we're migrating using the one-project-per-repo layout, thank you.

#2: unfortunately, things are not so simple on this issue. Problem is that renames which occourred on the hierarchy prevents the import to include all the changesets since some of them are considered out-of-scope (i.e.: importing /repo/unit0/product/ and its descendants when for example /repo/unit0/product/subproductA had been moved from /repo/unit1/subproductA) by the importer.

We also tried to workaround the problem using a combination of dumps and filtering (svnadmin dump + svndumpfilter) but it did not work due to the svn way of handling renames/copies and the limitations of svndumpfilter itself.

Fortunately, we only have a few hierarchies subject to this problem, for a total few dozens changesets (on a total > 10k revs in our repo) of not-so-relevant history so we are considering alternative solutions instead (i.e. not migrating them but adding sources directly to Plastic).

As for Subversion itself, I have frankly to say that after some years we've quite enough of it and so we're looking for its decommissioning instead of making it redudant... ;-)

Bye,

Alessandro

[Guest]

Hi, alextxm:

Fortunately, we only have a few hierarchies subject to this problem, for a total few dozens changesets (on a total > 10k revs in our repo) of not-so-relevant history so we are considering alternative solutions instead (i.e. not migrating them but adding sources directly to Plastic).

In this case I think it's not a bad idea, then, to add those files directly to Plastic.

Bye,

Luis