Aaron K Posted December 19, 2011 Author Report Share Posted December 19, 2011 Hi Manu, that's my fault. I will resend a new file. I had edited that file but forgot I had done that. The filename is actually an escaped UTF8 filename in reality. Link to comment Share on other sites More sharing options...
manu Posted December 20, 2011 Report Share Posted December 20, 2011 Don't worry Aaron, I'll take a look into it today. Link to comment Share on other sites More sharing options...
Aaron K Posted January 12, 2012 Author Report Share Posted January 12, 2012 Hi guys. Happy New Year to you all. Just checking in to see if there's been any progress at all with my issue? Many thanks Aaron Link to comment Share on other sites More sharing options...
manu Posted January 12, 2012 Report Share Posted January 12, 2012 Hi Aaron, Happy new year for you 2! Sorry for the delay... I've just imported your "nodata" package without problems using the BL239, can you check if you can do the same? Import output: 142 branches 34166 modified files found refering to an SHA instead of a mark 34166 modified files 00,0 Mb in blobs. 0 blobs Manu Link to comment Share on other sites More sharing options...
Aaron K Posted January 25, 2012 Author Report Share Posted January 25, 2012 Hi Manu. When Pablo was looking at the issue we already tried the nodata and it imported fine. It's when there's actual data that it's a problem. Link to comment Share on other sites More sharing options...
manu Posted January 26, 2012 Report Share Posted January 26, 2012 Hi Aaron, I'm working on it right now. I will let you know the progress. Link to comment Share on other sites More sharing options...
manu Posted January 26, 2012 Report Share Posted January 26, 2012 Hi again Aaron, I think I have it! First, all your paths are starting with "@DEV.600" I haven't seen before that kind of path!! The "@" is very very weird. Replace all "@DEV" with "DEV", it's going to be safer. Second, the line 5635 has another weird starting path name, notice the ' " ' char: M 100644 916c5799216c45de2eea4e52669a1424c573aa26 "DEV.600/Plugins/Kaspersky SDK/doc/\371\341\337G\253 \272\341\361\341\363\341\321\274d\321 \363\253\273a\253\337d.doc" Remove that quote char and also that strange .doc name, leave the line like this: M 100644 916c5799216c45de2eea4e52669a1424c573aa26 DEV.600/Plugins/Kaspersky SDK/doc/MyWeirdDoc.doc" I think is going to work this time! Give it a try! Link to comment Share on other sites More sharing options...
Aaron K Posted February 8, 2012 Author Report Share Posted February 8, 2012 Hi Manu. I think we're getting somewhere! I went into the .fe file with a hex editor and renamed all instances of the file, removing the quotes as well. Now it doesn't stop on the same error, but I am getting an error while processing the same list of files: Error: There has been an unexpected error "Packets larger than max_allowed_packet are not allowed.". For more information check the server log. The server log shows something like: SAMBO ERROR BlobStore - An error occurred in SaveObjectDatas Packets larger than max_allowed_packet are not allowed I'm running MySQL5.5. and if I perform a mysql --verbose --help I get a max_allowed_packet of 16MB, which from what I understand is much larger than Plastic's 4MB buffering that it uses. Do you have any ideas how to fix this one? I think once I can get large blobs into the repository it should hopefully work! Link to comment Share on other sites More sharing options...
Aaron K Posted February 8, 2012 Author Report Share Posted February 8, 2012 Update. Looks like things are working now which is fantastic! I went into my .ini file for MYSQL and upped the max_allowed_packet to 256MB. 32MB still caused the error so I just chose something large. I'd still be interested to know if there is some problems here because I thought a setting of 4MB or greater would work with Plastic. Manu, I was wondering if there's going to be a fix for the filename issue. It seems fast export will export filenames as escaped printable characters if they are not plain ansi, so maybe support needs to be added into Plastic's fast import. Many thanks, and I'll keep you posted as I migrate more VSS projects. Aaron Link to comment Share on other sites More sharing options...
manu Posted February 21, 2012 Report Share Posted February 21, 2012 Hi Aaron! nice to hear it's working now! Please check the following article about tuning the MySQL, your MySQL performance will be higher following the guide. http://www.plasticscm.com/infocenter/technical-articles/kb-how-to-fine-tune-mysql-performance-for-plastic-scm.aspx Link to comment Share on other sites More sharing options...
Aaron K Posted April 25, 2012 Author Report Share Posted April 25, 2012 Hi guys. I'm just going to bump this because I have discovered the import is still failing. It's to do with the spaces in directory names. The fast export from GIT leaves the filenames as is without quotes and so the import is getting confused as to where the beginning and end of the filenames are. It's hard to trust what's in the repository now unfortunately. Any progress/workaround for this issue? Thanks Link to comment Share on other sites More sharing options...
manu Posted April 25, 2012 Report Share Posted April 25, 2012 Hello Aaron, Soho has faced this problem and he did some perl magic to fix it: http://www.plasticscm.net/index.php?/topic/930-importing-tfs-project-into-plastic/page__fromsearch__1 You can also change the Git version a retry the export: http://www.plasticscm.net/index.php?/topic/665-git-bug-in-fast-export-command/ Link to comment Share on other sites More sharing options...
Aaron K Posted April 27, 2012 Author Report Share Posted April 27, 2012 Hi Manu. I looked at the link and that seems to quote the replacement commands correctly but now I'm getting "illegal character errors". Note this are not the same ones as before as I'm just doing a small part of the tree at the moment as a test. Here's the error. Error processing changeset mark 4. Parent cset mark: -1. Parent cset: -1 Illegal characters in path. blob mark :1 blob mark :2 blob mark :3 reset refs/heads/master commit refs/heads/master mark :4 author redacted <redacted@redacted.local> 1202352226 +0000 committer redacted <redacted@redacted.local> 1202352226 +0000 data 8 M 100644 :1 @DEV.700/Components/UDB Providers/ActiveDirectory/ActiveDirectorySearch.cpp M 100644 :2 @DEV.700/Components/UDB Providers/ActiveDirectory/ActiveDirectorySearch.h M 100644 :3 @DEV.700/Components/UDB Providers/ActiveDirectory/ReadMe.txt Error: Illegal characters in path. 2012-04-27 12:03:27,428 3240 (null) (null) (null) ERROR cm - Error: Illegal characters in path. 2012-04-27 12:03:27,443 3240 (null) (null) (null) ERROR cm - at System.IO.Path.CheckInvalidPathChars(String path) at System.IO.Path.GetFileName(String path) at nz.a(AddInfo A_0, String A_1, ArrayList A_2, ah A_3, aae A_4) at nz.a(ArrayList A_0, ah A_1, aae A_2) at nz.a(IList A_0, ah A_1, aae A_2) at xq.a(d A_0) at xq.b(d A_0) at xq.a(a A_0) at xq.b(a A_0) at xq.a(as3 A_0, Int64[] A_1) at if.a(as3 A_0) at gi.a(RepositoryInfo A_0, String A_1, a A_2, String A_3, String A_4, Boolean A_5, Boolean A_6) at mz.a(b A_0) at w1.c(String[] A_0) Then I looked for :4 in my .fe file (as you suggested last time I had an error) and this is what I get. NOTE: No mangled filenames like I was getting before. reset refs/heads/master commit refs/heads/master mark :4 author redacted <redacted@redacted.local> 1202352226 +0000 committer redacted <redacted@redacted.local> 1202352226 +0000 data 8 Vss2Git M 100644 :1 @DEV.700/Components/UDB Providers/ActiveDirectory/ActiveDirectorySearch.cpp M 100644 :2 @DEV.700/Components/UDB Providers/ActiveDirectory/ActiveDirectorySearch.h M 100644 :3 @DEV.700/Components/UDB Providers/ActiveDirectory/ReadMe.txt blob mark :5 data 1209 #include <stdafx.h> #include "UserdatabaseCache.h" Any idea why this might cause an issue. If I try the export with nodata and then import, it imports OK (But with no data obviously) Thanks Link to comment Share on other sites More sharing options...
manu Posted May 2, 2012 Report Share Posted May 2, 2012 Ummm I really don't like the "@DEV.700" prefix in all the paths. Let's try something fast. Edit the :4 mark and remove the three prefix from the path, let's see if it's able to process the changeset. Link to comment Share on other sites More sharing options...
Aaron K Posted May 2, 2012 Author Report Share Posted May 2, 2012 Hi Manu. I ended up writing my own .fe file fixer which does 2 things. Fixed up the old octal filename characters (/372 etc) I was getting in some filenames, and also quotes certain strings in 'R' commands that were causing a problem due to spaces in the path names. The perl script just seemed to mangle my .fe file and made it unusable, causing the error. My utility works fine and we have our code in Plastic now and are finally live! Link to comment Share on other sites More sharing options...
manu Posted May 3, 2012 Report Share Posted May 3, 2012 That's good news! Can you tell me if you finally had to remove the "@DEV.700" substring? Link to comment Share on other sites More sharing options...
Aaron K Posted May 3, 2012 Author Report Share Posted May 3, 2012 Hi Manu. Nope I didn't have to remove the @DEV.700. That's just the convention we use here (legacy) for naming our development trees. Link to comment Share on other sites More sharing options...
manu Posted May 4, 2012 Report Share Posted May 4, 2012 Ok! Thanks, it sounds strange for me but it's fine if it's a name convention. Link to comment Share on other sites More sharing options...
derkork Posted October 20, 2015 Report Share Posted October 20, 2015 Sorry for re-opening an age-old thread but adding the --stats parameter still breaks the import in 2015. Maybe that parameter should be removed if it isn't working. Link to comment Share on other sites More sharing options...
manu Posted October 20, 2015 Report Share Posted October 20, 2015 Yes.... You are very right... We should remove it, I'll try to push it. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.