V3 > v4 Info

[db-esm]

Is there any way around the "branch will be discarded" issues with trying to upgrade from v3 to v4 via fast-export?

 

Our main repository had almost every branch "discarded" in fast-export, even top-level branches.

 

Is there anything we can do with the v3 repository to help export it better?

 

Is there any other way to upgrade?

[db-esm]

In this thread: http://www.plasticscm.net/index.php?/topic/1394-3x-to-41x-migration/

 

someone says: "...all your branches are inheriting from "last" and they are not exported to Plastic4. There is a possibility to indicate manually a different father, modifying and checking branches one by one, but I suspect you have a lot of branches and it will be a tedious process."

 

How is this done?  I might be willing to do this for at least some of our branches, if this is possible.

[GPF]

Hello,

 

I am also interested in how to manually fix discarded branches when migrating from 3.x to 4.x. Would appreciate a reply as this issue is just holding us back from migrating to 4.x.

 

We are using the latest .38 revision of Version 3.x.

 

Is the fix dependent on the database-backend? Looking forward to hearing from Codice tech support.

 

Many thanks,

GPF

[GPF]

Forgot to mention ...

 

The discarded brances were created using "Dynamic Inheritance from parent branch". When I invoke the discarded branch's properties dialog box and change the Branch Base from "None" to the specific changeset in the /Main branch, it will link the LAST changeset of the discarded branch to the specific changeset in the /Main branch. This is not what we want - we want to somehow link the FIRST changeset of the discarded branch to the specific changeset in the /Main branch. I think this will solve our problem because other branches that have explicit an changeset as their base have exported successfully.

 

Kindly advise and thanks again.

[manu]

Hi there!

 

Indeed branches with dynamic inheritance can't be exported into Plastic SCM. This is because these kind of branches are not having an static base, they are always starting from the newest changes of the parent branch.

 

This kind of branches are not allowed in Plastic SCM 4. All the Plastic SCM 4 branches are using an static base (changeset, label). We did it due to our new DAG core model and the idea of being able to reproduce a changeset as it was, an static object.

 

That's being said there's an option to manually specify the base of the branches without a base.

 

There's a "--parentsmappingfile=<filename>" parameter where you can specify the parent relationship mapping. The format is:

 

156211 256209
148667 148666
...

Two columns, the first column is the changeset and the second column its parent. The first one is the first of your non exported branch and the second one the parent it will have in Plastic SCM 4.

 

If you are able to guaranty which is the parent for your non exported branches this is your way.

[GPF]

Many thanks for your reply. The above parameters resolved our problem with branches that do not have a static base. These brances are now exported out of V3 and importable into V4.

 

GPF

[GPF]

Hello again,

We've encountered a few other problems with some unexportable branches.

1. in a child branch, the first changeset is pointing to LAST in the parent branch while the last changeset is pointing to the correct changeset # in the parent branch. In effect, branch explorer is showing 2 parent links for this branch. I believe this occured because the branch was initially created using a dynamic link and then later on after the branch contained some changesets, the branch property was changed from dynamic to a static changeset #.

Is this problem fixable using the --parentsmappingfile parm? I tried different combinations and it still didn't export the branch.

2. in another child branch that contain a number of changesets, some of these changesets are pointing to different parent changesets. For example, the first changeset has a static base changeset #xxx on the parent branch, the third changeset has a static base changeset #yyy on the parent branch and the last changeset has a static base changeset #zzz on the parent.

The cm fast-export command will reports this branch as "Discarding branch <branch>. It is not smart or it starts from LAST". However, the branch property indicates a static base changeset #.

Again, Is this problem fixable using the --parentsmappingfile parm?

 

I guess the problem that is common to both above is when a branch has more than 1 parent link.

[manu]

Hi,

 

In those branches that are having more than one parent base, do they have a rebase operation after the new parent change? I mean, a  merge operation from the branch where the new parent is from.

 

You know that the regular rebase operation in Plastic SCM 3 was:

 

1) Change the parent changeset.

2) Run an update operation.

3) Merge from the parent branch.

 

If it's having the merge operation the exporter should take the branch into account, at least the last changeset in the candidate branch.

 

 

Again, Is this problem fixable using the --parentsmappingfile parm?

 

I'm afraid the mapping file will not work in this scenario, at least it's not the desired scenario for the mapping file functionality.

[GPF]

Hi Manu,

Thanks for your reply.

Regarding the issue #1 in post #7 above, is there a way to delete a branch base link, created via a regular rebase operation, from the repository? If I could delete this link, I am confident this unexportable branch can be fixed with the --parentsmappingfile.

GPF

[manu]

Hi GPF,

 

deleting that link is not possible and it's even dangerous.

 

I'm not sure if the mapping feature is useful in that scenario, I'm afraid that it was not designed to work in that way.