Error fast-import with quoted M commands

[nukefusion]

Hi,

 

I'm really hoping someone can help. I'm trying to transition an SVN repository to Plastic SCM. If it wasn't for the wonderful things I've heard about Plastic I would have given up 2 days ago. Can I just say that the transition process right now is painful, and I dare say it puts a lot of people off moving to Plastic.

 

Ok, so my problem. I have cloned an SVN repository using GIT. I have then fast exported my GIT repository:

$ git fast-export --all -C --tag-of-filtered-object=drop --signed-tags=strip >   repo.fe

Now I try to import that fast export file. BANG, it blows up with illegal characters in path at mark 2.

 

I fast-export with the NO-DATA option and find mark 2 and discover that M commands with quoted paths (because they have spaces in) cause the Plastic import to blow up (if I remove them that mark gets processed).

 

I can see that Soho struggled with this issue here: http://www.plasticscm.net/index.php?/topic/930-importing-tfs-project-into-plastic/?p=5248

It seems nobody could really help him and he had to craft his own perl script to start mashing the export file. Unfortunately, after jumping through hoops for a couple of days I feel that fast-export file mashing via perl script is above the threshold of what I'm prepared to do to try and get this working.

 

Can anybody help with this before I give up?

[manu]

Hi nukeFusion,

 

 

you have two options:

 

1) send to us the nodata package and we'll try to find out the problem.

2) Download the new 4.2 release and give a try to the new GitSync feature. You will need to set the git server as a server. (http://git-scm.com/book/ch4-2.html, http://git-scm.com/book/en/Git-on-the-Server-Public-Access, http://rwehner.wordpress.com/2010/03/01/a-simple-way-to-create-git-repository-on-a-server-machine-connecting-via-ssh/) or upload the repo to GitHub or Bitbucket.

 

This is how the GitSync works

 

 

or 

 

 

[JakubH]

I was transferring our data from CVS to Plastic (through GIT) and I can confirm that it was not a piece of cake. At all. It took me several weeks. I spent a lot of time configuring (and even editing) cvs2git and tuning my own C# utility, which made a lot of changes in a fast-export file to made Plastic to import it as we want. One of those changes was removing quotes in M commands.

 

But I think that importing from SVN with shorter history than we had, wouldn't be so hard. Though some fast-export file tuning would be probably still necessary. Or you can try an alternative way, as Manu proposes.

[nukefusion]

Hi Manu,

 

I've already identified the problem. I was running git 1.8.0 on windows and using the latest version of Plastic and the quotes around the paths were messing things up. I believe a number of users have had this issue including Soho and it's just never been fixed. As it is I reverted to an earlier versions of Git 1.7.5 and this seemed to import successfully.

 

I then had to circumvent some other problems, MySql packet size and the fact that Plastic does not seem to be able to deal with the fact that Git doesn't delete removed folders so I had these "orphaned" folders in my workspace.

 

After this I *seemed* to have a working solution. However, I have now discovered something more worrying - several files are empty, having a size of 0 bytes. So somewhere along the line my source code is getting chewed up. This is a real shame as I just don't know now whether I can trust Plastic not to trash my source. The files in question are fine in my SVN and Git repo's so I can only assume that Plastic is at fault. I'm only grateful that I have worked this out now and not later.

[manu]

Hi, 

 

1) Git doesn't track directories so it's impossible to get a "Delete directory" from a git fast-export package. Empty directories can be deleted in the last repository changeset with a very simple tool.

2) The MySQL max packet size must me increased in order to work fin with Plastic, as well as other parameter to increase the performance of MySQL and Plastic. http://www.plasticscm.com/infocenter/technical-articles/kb-how-to-fine-tune-mysql-performance-for-plastic-scm.aspx

3) I'm not sure but I think the issue you are having with the paths is related with this Git bug -> http://www.plasticscm.net/index.php?/topic/665-git-bug-in-fast-export-command/

4) Regarding the empty files. Please check if the fast-export file is having the content exported fine, although not impossible it's unlikely having a bug reading and inserting data.

 

As I said before if you don't feel comfortable with the fast-export/import mechanism you can give a try to the new 4.2 Gitsync feature. 

[nukefusion]

Hi Manu,

 

Thanks for your reply.

 

Points 1 and 2 I'm fine with and I've resolved those issues.

 

For point 3, I don't think it's that bug that I'm hitting at all. Git is exporting the paths correctly, it's plastic that seems to have issues importing it. What versions of Git has Plastic been tested with? Are there a list of supported versions somewhere? I've looked at the forums and I'm not the only person that had this problem, see http://www.plasticscm.net/index.php?/topic/830-fastimport-with-blanks-in-paths/ which was posted almost a year ago. Was that ever investigated or addressed?

 

Point 4, the fast export file is over 1gb in size so it's kind of impractical to check it manually, although I can tell you it re-imports back into git absolutely fine - no missing data.

 

Techinically, I'm comfortable performing the fast-export/import procedure - it's just a pain and quite simply, it doesn't appear to work very well.

 

I'll evalute the new GitSync feature and report back on how it goes. Thanks for your help thus far.

[nukefusion]

Ok, so I'm trying GitSync, which seemed to be working. I've got a git repository on my local machine and started doing an import which got to about half way but then I had a network drop-out.

 

I figured I could restart the import from where I left off, but now I get a null reference exception:

 

 

Receiving references... \Receiving references... -both contributors.Receiving references... OKCompressing objects... OKDownloading... OKProcessing objects:... |- 209 changesets to pull- 0 changesets to pushThere are changesets to push and pull.Will pull the remote changes then you'll have to merge them and push the changes back.Processing objects:... OKImporting... | 1/209Error: Object reference not set to an instance of an object.

 

I'm going to try zipping up my local git repository and sending it up to my Plastic server and see if I can GitSync there to avoid any network issues. If that doesn't work I'm not sure what else I can try. I will report back here.

 

[nukefusion]

Ok guys,

 

This is not good. I got the GitSync working by running the Git clone and subsequent GitSync on the server that was going to be running Plastic. Everything seemed fine and I did some coding and checked in some changesets yesterday evening to test - all good.

 

Today I am in a different location and have attempted to create a workspace and update it on another machine and I'm getting an "Update Operation Report" with failures in - "Object reference not set to an instance of an object". 5 folders cannot be updated and the source inside them is missing. I have no idea if it still exists on the server or if it's been destroyed....

 

Ok, as I am writing this I have found that I CAN update if I open the Plastic SCM GUI from the Start menu (I'm running Windows) and update my workspace from there - but doing it from the explorer extension caused the above error.

 

Guys! I want to love your product but these errors are scaring the **** out of me. I started off this post ready to revert back to another VCS but I want to stick with Plastic. Can I get my data back out easily if this doesn't work out?

[manu]

Hi nukefusion,

 

so it's seems that all is fine and the problem is with the Shell Extension, right?

 

Please confirm that you can perform fine with the GUI and the CLI.

[nukefusion]

Hi Manu,

 

Yes, the problem seems to lie with the shell extension. The GUI and CLI work correctly, thanks for your help. Other than that I had the one problem with GitSync when the network connection dropped out half way through before I did the import on the server machine itself. Are these bugs that you'll be able to look into? I'm afraid it didn't provide any other diagnostic information that may help, they were just null reference exceptions.

 

Seems to me that the new GitSync feature is a major step forward and hopefully as it develops it will become more stable. I imagine this has got to be a be a major stumbling block for companies and individuals wanting to try your software, especially those transitioning from SVN or TFS. If the import process was simpler and smoother less people might be put off and that would be good for everyone because now it's up and running it's looking great.