MKS problem with projects

[Johan]

Hello,

We have a large MKS project (Integrity 2007) where every sub-folder is a sub-project itself. The project is checkpointed ~180 times, always from the root project.

I'm trying to use the 1.2 improved MKS SVN importer but I get the following error:

Code: Select all

09:18:05,606 [main]  INFO Exec:84 - exec C:/Program Files/MKS/IntegrityClient/bin/si.exe rlog --batch -R --project=e:/Source/patches/projects/audio/project.pj --projectRevision=1.30 --headerformat=MEMBERNAME:{membername}
RELMEMBERNAME:{relativemembername}
ATTR:{attributes}
FORMAT:{format}
--format=REVISION:{revision}
AUTHOR:{author}
DATE:{date}
DESCRIPTION:
{description}
END_DESCRIPTION
--trailerformat=**********
audio.c
09:18:05,715 [stderr]  INFO Exec:84 - *** MKS125211: The project file e:/Source/patches/projects/audio/project.pj is not registered with the current server.
09:18:05,919 [main] DEBUG Exec:80 - Process exit value: 128


This is most likely not a problem with the importer. Both e:/Source/patches/projects/project.pj and e:/Source/patches/projects/audio/project.pj are sub-projects that have been dropped and are no longer part of trunk but exist in previous checkpoints i.e. revision 1.30 above does exist.

I can get the same error in the GUI client by doing this:

• Expand project view to e:/Source/patches/
• View project history for e:/Source/patches/project.pj
• View project for an old revision that contains the sub-project
• Expand e:/Source/patches/projects/audio/
• Try to view project history for e:/Source/patches/projects/audio/project.pj -> MKS125211 error

I can then do a workaround:

• Try to view member history for e:/Source/patches/projects/audio/audio.c that is part of the sub-project -> this works
• Try again to view project history for e:/Source/patches/projects/audio/project.pj -> now it works

This works for the project until someone restarts the MKS server. I guess this is a problem in the MKS server with dropped sub-projects containing other sub-projects. We have a support issue with MKS regarding this but are still waiting for their latest answer. We have a lot of these types of dropped sub-projects in the root project so it is "impossible" to do this manually for every error we encounter.

Is there a way to modify the svnimporter to do something similar as the workaround above?

[kencorbin]

Hi There,

The importer never retrieves project history for subprojects. We make the assumption that all checkpointing and branching has been done at the main project level and that any subproject branches and checkpoints are derived from man project branches and subprojects. Which means that whatever problem the importer is hitting is possibly related to but not the same as the one you are having viewing subproject history.

Curiously, there is another MKS support thread where another client is running into an identical problem. One starts suspecting that recent version of Source Integrity have some subtle change in the way deleted subprojects are processed that is throwing things off. If you browse through that thread, you will find a detailed description of just what the importer is trying to do when it fails. We are still working through what the best solution might be.

There is one easy, but possibly not optimal solution. I could make that error condition log an error and continue processing rather that terminate the migration. I don't know how acceptable that would be.

Good luck,
-Ken

[Johan]

Hi Ken,

I've been away for a few days. Thank you for your reply!

It would be nice to be able to just log the error condition and then continue. What do I need to do to accomplish that? This would hopefully allow us to see how many occurences of the problem we have. We always checkpoint and create development paths at the root project.

I know the importer uses rlog and not project history but it was one way to trigger the same error condition in the client. I've tried to figure out what the client does when it succedes but no luck yet.

This is just a speculation but I suspect the error occurs due to our project structure where every folder is a subproject (root - main project, Sx - sub projects, Mx members) that looks like this:

Code: Select all

root
  |-- S1
  |   |-- S2
  |   |   |
  |   |   |-- M1
  |   |   |-- M2
  |   |
  |   |-- S3
  |   |   |
  |   |   |-- M3
  |
  |-- S4
      |-- M4


Now lets say this happens:

• Drop S1 above
• Continue to work on trunk and create new checkpoints on the root project
• Now we want to issue rlog for M1 in S2
• We need to specify path to subproject S2 and revision for S2 when M1 was part of S2
• This fails

I can't find a way to also specify versions for S1 and root because S2 is in a dropped S1 project that is no longer part of latest root revision. I guess this is why the command fails.

[kencorbin]

Sorry I haven't been tracking this a closely as I should.

Your subproject structure shouldn't cause a problem as long as you are locating each subproject in its own subdirectory. If you don't do this, all of the root level files for the different subdirectories end up on the same sandbox directory, which rapidly gets unmanageable. Which is why nobody does things that way. Though I have seen projects where all of the subprojects lived in the same directory, but each subproject put all of its files in a subdirectory with the same name as the project. A little messy, but it seems to work. The importer should handle both schemes.

When you delete the S1 subproject, the subproject doesn't really go away. It still lives on the MKS server with the same path that it used to have. It just isn't in the list of members of the root project anymore. With Source Integerity 8.0, you could still query S1 or its subprojects by specifying that server location with a -P switch, which is what the importer attempts to do. There is another thread discussing problems another user has been having in this situation, which leads me to believe that something may have changed in recent versions of Source Integrity. Your problem is to figure out just what parameters we need to pass with an command line rlog command to query the now deleted subproject. The 8.0 version didn't use a database, you could find the real project paths by logging into the server and examining the file structure there. It is starting to sound like things have changed since then.

If you are still on MKS support, they can probably help you. If not, then things could get very sticky.

Good luck,
-Ken

[kencorbin]

And it seems you aren't the first user to run into something like there. There already is a configuration option
mks.exec.continue
that you can set to yes if you want the importer to continue running when this paraticular error occurs. The dump file generated with this option on is highly suspect, but it is good way to get a list of just how ofter you are going to run into this problem.

Good luck again,
-Ken