sray Posted December 2, 2011 Report Share Posted December 2, 2011 Hello, We've just installed the latest versions of both 3.0 and 4.0 to facilitate migrating our databases from 3 to 4 using fast-export/import. I've run into a couple of problems. Problem 1: After import into 4, new check-in operations start as changeset number 1 rather than n+1! For example, I have a small project with 19 changesets made in version 3. I did a fast-export and then a fast-import to 4 and everything looked great. I then added 2 files to the project which should have created changeset 20. Instead, the last changeset in the project is listed as changeset 1 and it inherited the same comment from the real changeset 1 (though the two have different GUIDs. In the branch explorer, I now have two home icons displayed, one on each of the changeset 1's (see image - 1a.jpg has 1st changeset 1 selected, 1b.jpg has last changeset selected). In the image you can see the properties for the last changeset which are really the first changeset properties. This does not give us confidence in the import and the integrity of the database, especially for much bigger projects. Problem 2: In some of my projects, I include a folder with web links for reference. Some of these have filenames with odd, but legal characters (for example, a long dash "–" rather than a short dash "-"). Unfortunately, when exporting from the .30 release of 3, some of these odd characters are replaced with "?" characters in the exported file. Import into 4 works fine, but when I attempt to update a workspace, Plastic complains it can't create the file (because of the illegal ? character the file name now contains). My solution was to record which databases had this problem and delete them. I then manually searched through those export files for file names with illegal characters and edited them to something reasonable. Finally, I reimported the files and then workspace updates worked ok. A minor, but annoying issue. Luckly, we don't have many databases with this issue. In any case, the first issue is really preventing us from migrating to 4.0 at this time. Any ideas on this? Thanks, Steve Link to comment Share on other sites More sharing options...
manu Posted December 2, 2011 Report Share Posted December 2, 2011 Hi Sray, I'm going to try to reproduce your error. Give me a little more information, 1) Exactly versions of 3.0 and 4.0. 2) The commands you use to export and import. 3) Are you using an empty repository to perform the import, right? Regards, Manu Link to comment Share on other sites More sharing options...
manu Posted December 2, 2011 Report Share Posted December 2, 2011 Hi again Sray, we have uploaded the latest 3.0 release with a lot of fast-export improvements. This release is the BL187.32 please retry the fast-export with this new release. You can download it from our download site: https://www.plasticscm.com/download/oldreleases.en.aspx Regards, Manu. Link to comment Share on other sites More sharing options...
sray Posted December 3, 2011 Author Report Share Posted December 3, 2011 Thanks for the response Manu. Here's a bit more details: 1) Exactly versions of 3.0 and 4.0. Source was version 3.0.187.30 Destination was version 4.0.237.2 2) The commands you use to export and import. Source commands from the 3.0 client directory: .\cm fe CardViewerWPF@localhost:8084 move fast-export.dat \slr\CardViewerWPF.dat Destination command from the 4.0 client directory: .\cm fi CardViewerWPF@localhost:8087 \slr\CardViewerWPF.dat 3) Are you using an empty repository to perform the import, right? Yes, this was a fresh 4.0 install, although I did import about 8 repositories total in the above manner. I noticed this problem on two repositories, but didn't check the rest. Here is some additional information since my post that may help: I copied the 3.0 databases from work to a Windows 7 virtual machine at my home with fresh installs of the 3.0 and 4.0 (same versions as above). I stopped the 3.0 server, substituted in the copied databases from work, and then restarted the server. I then exported as I had done at work. I then intended to import to 4.0 as I had done at work, but had user auth issues since I'm not running active directory. So I did a quick edit of the .dat export files changing author and contributor entries to "all <all>" (and changing the "?" in filenames to "-"). I then imported these files into 4.0. In this case, all was fine as new checkins incremented the changeset numbers to the next value properly. So the differences in this case are, I slightly edited the .dat files, I'm not using active directory, and the underly OS is different. Here I used Windows 7 x64 while at work we are using Windows Server 2003 R2 (32-bit). Is it possible the issue is with the older operating system? Next week, I'll try migrating the exports unedited by installing PlasticSCM (3 and 4) on a Windows 7 x64 system that is part of our active directory. Once in 4, if all checks out, then I'll copy the version 4 databases to our primary server and recheck. Hopefully we'll be up and running then. Steve Link to comment Share on other sites More sharing options...
manu Posted December 5, 2011 Report Share Posted December 5, 2011 Hi Steve, ok, in oder to generate the packages remember to use the release BL187.32. Regards, Manu Link to comment Share on other sites More sharing options...
sray Posted December 5, 2011 Author Report Share Posted December 5, 2011 Hi Manu, Thanks for the pointer to BL 187.32. I tried this out today by moving our databases from the Win 2003 server to my Win7 system with 3.0.187.32 installed. This version appears to fix both of my issues (file naming and repository issues). Unfortunately I didn't get to try an export directly from the server as our IT staff was out and I don't have the appropriate permissions. In any case, I'm happy now and have migrated all repositories to 4.0 and tested checkins working properly. It is so nice working with the new UI, especially the updated Branch Explorer! Thanks for your help! Best regards, Steve Link to comment Share on other sites More sharing options...
manu Posted December 7, 2011 Report Share Posted December 7, 2011 Hello sray! I'm happy to hear everything is running! Enjoy the new version! Regards, Manu. Link to comment Share on other sites More sharing options...
mvdzwaan Posted December 7, 2011 Report Share Posted December 7, 2011 I've tried the above procedure and have succesfully transfered a number of repositories from 3.0 (32) to 4.0 (237.2) After the transfer I always need to active the user licenses again (cm au), no problem there. But 3 repositories fail to fast import. About halfway through cm fi stops and gives changeset information and the error "The user S-1-5-21-..... appears as an inactive user because his/her license has been deactivated. Please activate it and try again." All users were activated beforce the fast-import. How could this be resolved ? Link to comment Share on other sites More sharing options...
sray Posted December 7, 2011 Author Report Share Posted December 7, 2011 I've tried the above procedure and have succesfully transfered a number of repositories from 3.0 (32) to 4.0 (237.2) After the transfer I always need to active the user licenses again (cm au), no problem there. But 3 repositories fail to fast import. About halfway through cm fi stops and gives changeset information and the error "The user S-1-5-21-..... appears as an inactive user because his/her license has been deactivated. Please activate it and try again." All users were activated beforce the fast-import. How could this be resolved ? Hi, I just encountered this exact same issue on my last database I needed to migrate. While looking into this, I noticed some other oddities in user activations. I started a new topic about this in this forum titled "Users deactivating on fast import" (http://www.plasticscm.net/index.php?/topic/657-users-deactivating-on-fast-import/). Steve Link to comment Share on other sites More sharing options...
mvdzwaan Posted December 8, 2011 Report Share Posted December 8, 2011 My users don't disappear, but are shown as inactive after performing the fast-import. Note that these users are AD users, and have allready been activated after previous fast-imports. One solution seems to be the following : * do fast-import, repository does not exist so will be created * fast-import will fail because of inactive users (previously active, but de-activated by the failed fast-import) * activate the inactive users * do fast-import, on just created (empty?) repository * fast-import seems to skip the user creation on the already existing repository and imports just fine. My only worry now is wether the first import conflicts with the second one, or to put it another way, what did the first fast-import do to the repository Link to comment Share on other sites More sharing options...
mvdzwaan Posted December 8, 2011 Report Share Posted December 8, 2011 My only worry now is wether the first import conflicts with the second one, or to put it another way, what did the first fast-import do to the repository Unfortunately, this does not seem to work properly. The first fast-import had import 30 changesets already, and after the second fast-import these 30 changesets were duplicated. 30 of them had the correct timestamp, 30 of them all had the same timestamp as the root (changeset 0). So I need to find a way to cleanup the repository after the first fast-import (looking into obliterate ?) Link to comment Share on other sites More sharing options...
mvdzwaan Posted December 8, 2011 Report Share Posted December 8, 2011 Unfortunately, this does not seem to work properly. The first fast-import had import 30 changesets already, and after the second fast-import these 30 changesets were duplicated. 30 of them had the correct timestamp, 30 of them all had the same timestamp as the root (changeset 0). So I need to find a way to cleanup the repository after the first fast-import (looking into obliterate ?) using --export-marks and --import-marks parameters does not seem to work... Seconds fast import still performs an import of the already imported changesets. The marks file seems to contain the correctly imported changesets from the first fast-import Link to comment Share on other sites More sharing options...
sray Posted December 8, 2011 Author Report Share Posted December 8, 2011 Mvdzwaan, Well, you gave me an idea that I'll try tomorrow. I'll manually create an empty repository, verify all required users are activated, and then do a fast import. If that works, then I just need to figure out why users are disappearing on server restarts... Thanks, Steve Link to comment Share on other sites More sharing options...
mvdzwaan Posted December 8, 2011 Report Share Posted December 8, 2011 Well, you gave me an idea that I'll try tomorrow. I'll manually create an empty repository, verify all required users are activated, and then do a fast import. If that works, then I just need to figure out why users are disappearing on server restarts... Worked like a charm. I created an empty repository, created all the users I knew would have to be created by the fast-import otherwise, and did the fast-import. Flawless this time. Only downside to this is I have to set all permission myself instead of having them created automatically but as I have full permission for everyone except ci on the main branch it's not a big deal. Link to comment Share on other sites More sharing options...
sray Posted December 8, 2011 Author Report Share Posted December 8, 2011 Mvdzwaan, Glad it worked for you. Unfortunately, it didn't work for me. Users still being automatically deactivated and branch manager shows no branches... Codice, any thoughts? Steve Link to comment Share on other sites More sharing options...
mvdzwaan Posted December 8, 2011 Report Share Posted December 8, 2011 Glad it worked for you. Unfortunately, it didn't work for me. Users still being automatically deactivated and branch manager shows no branches... Codice, any thoughts? I thought everything worked, but I'm having the same problem you had. I did a checkin and it became changeset 1.... Link to comment Share on other sites More sharing options...
psantosl Posted December 9, 2011 Report Share Posted December 9, 2011 We're looking into it right now. Link to comment Share on other sites More sharing options...
sray Posted December 9, 2011 Author Report Share Posted December 9, 2011 Last night I had the repo owner look at what I was doing and he noticed the the 3.0 source was corrupted (only showed 5 changesets in a single branch when he had 33 over 3 branches). Since this 3.0 repo was origionally an import from SVN, I started working with the SVN repo instead. To import this, I attempted to migrate it to Git first. Unfortunately, the import into git had fatal errors when doing a full migration with svn2git. So I'm concluding that the SVN source is actually corrupted. It turns out that the SVN repo was created when we were evaluating alternatives to ClearCase. Plastic won the evals, but we thought is was easier to import from SVN as many projects were already tested there and the import tool supported SVN. This worked in most cases. For this repo, we will go back to ClearCase as the source and migrate it directly to 4.0 and that should fix this last repo. Let me know if you have any suggestions on migrating from clearcase to plastic as I don't think clearcase has a fast-export... Thanks, Steve Link to comment Share on other sites More sharing options...
JorgGaubmann Posted March 30, 2012 Report Share Posted March 30, 2012 Has there been any resolution to this? I have been using v4 (239.2) for a while w/ integrated AD for user management. Just today I used fast-export/import to bring my 3.0 rep into my new environment. Now my current system is not usable due to creation of inactive users which match my current active ones (same issue as mentioned). I tried to Activate them, however I dont have permissions. Running cm whoami give me administrator.? In actuality, I really dont need to activate these users since they are from the old rep. However because the user names are the same as my current users, there is a confict.. I just need my current users to be set to the active ones. Thanks, Jorg Link to comment Share on other sites More sharing options...
manu Posted April 2, 2012 Report Share Posted April 2, 2012 Hi Jorg, I sent you an email regarding this issue. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.