Soho Posted May 3, 2012 Author Report Share Posted May 3, 2012 I am not completely out of the woods yet. It turns out that TFS has a well known and strange habit of using mixed cases for folders. This is transparent in a pure TFS environment since TFS ignores case when checking out. This results in a TFS to git export containing the same folders but with different cases. Apparently git checks out the repository with only one case, so the git checkout looks normal, but the Plastic import of git fast-export is corrupted. Plastic does not gracefully handle import of folders with different casing from a fast-export file. Quite possibly Plastic just follow the standard, but after the import the Plastic repository is corrupted. I found a hack on stackoverflow that claimed, that if you renamed all folders in TFS to it's own name, then the mixed cases problem would be reset. This is what I am trying now, but every try takes an hour or two, because there are a lot of changesets and many GB of data. Link to comment Share on other sites More sharing options...
Soho Posted May 3, 2012 Author Report Share Posted May 3, 2012 Ok, after more perl hacks I was finally able to pull the TFS repository into Plastic. There was still a single case duplicate folder, that I could fix in the fast-export file, since when I did, Plastic would go into an infinite loop when importing. The folder appeared solo in the Items explorer. No dups, but when I tried to rename the case to the desired case, Plastic complained that this was impossible, because a folder with that name already existed, even though that folder was not visible in the items explorer. Anyway, I was able to fix the last duplicate by merging the import branch to another. Then Plastic actually detected the duplicates and create specially name directories for the duplicates. That allowed me to delete the dup-folders and finally get a clean branch. Apparently Plastic had some way of handling case duplicates, but it seemed to be only half-hearted implemented. It only worked when merging. It would have been (very very) nice if Plastic had handled these quirks when fast-importing, when xlinking and when renaming, since this is where I hit the wall of problems. I know this is a corner case, but it is reported as a common problem with TFS, so if the Plastic people wants to get serious about capturing TFS bound customers, they should consider having a look at less agonizing TFS import. (Issues I have found are: 100% git-compatible fast-import, folder multi-case handling, quoted paths, paths containing spaces, octal file name encoding, author/committer encoding, probably a few more). All these issues are likely tiny issues to fix in code, but giant problems to identify and hack as I did. It should be more than a few lines of code to handle almost all issues in cm fast-import. I never solved the encoding problem. My name is still spelled with two ?? in the Created By column. Link to comment Share on other sites More sharing options...
manu Posted May 4, 2012 Report Share Posted May 4, 2012 Apparently Plastic had some way of handling case duplicates, but it seemed to be only half-hearted implemented. It only worked when merging. It would have been (very very) nice if Plastic had handled these quirks when fast-importing, when xlinking and when renaming, since this is where I hit the wall of problems. The duplicated folders (case sensitive names) are correctly handled in a regular use of the tool, for example if you use Plastic SCM under Unix, it's also well handled in the merge operation and if you try to update, in windows, a Unix repository with duplicated names you will get a warning error. To be honest this is the fist time we notice this behavior in the fast-import command, we will take a look into Git to know how to support this case. Would it be possible if you can send us your original TFS fast-export file without data? Just to have a real case to work with. I never solved the encoding problem. My name is still spelled with two ?? in the Created By column. We already have a task inside our bug tracking system to support this scenario. Link to comment Share on other sites More sharing options...
Johan Ung Posted July 12, 2017 Report Share Posted July 12, 2017 @Soho doesn't seem to be active here anymore, @manu do you know if the final version of the script ever got posted? I'm looking for a solution to fast-import a repo with åäö-filenames into plastic. Link to comment Share on other sites More sharing options...
manu Posted July 12, 2017 Report Share Posted July 12, 2017 Hello Johan, Nop, I'm sorry I didn't receive it but I'll DM you Soho's email, you can CC me if you want mlucio at codicesoftware dot com. Maybe he can share a copy. Link to comment Share on other sites More sharing options...
calbzam Posted July 12, 2017 Report Share Posted July 12, 2017 Hi @Johan Ung, I've been reviewing our issue tracker and we actually fixed the problen with the åäö-filenames. Please check the release notes: [2012-06-13] 4.1.10.2954.2.12.297 Fast-export command has been modified to support special characters in branch names, label names and owner names (author/commiter).Fast-import command has been also modified to use only UTF8 to avoid encoding problems. Regards, Carlos. Link to comment Share on other sites More sharing options...
Johan Ung Posted July 13, 2017 Report Share Posted July 13, 2017 Hi @calbzam, does it handle the octal notation of utf8 that git fast-export produces for file names though? Example line in the git fast-export:ed file: M 100644 :22 "test-med-\303\244.txt" Comments and authors are imported correctly into plastic, since git fast-export has as different utf8 notation for those fields (one wonders why). Edit: Forgot to attach screendump of problem in Plastic BR, Johan Link to comment Share on other sites More sharing options...
calbzam Posted July 13, 2017 Report Share Posted July 13, 2017 Hi, We haven't been reported any issue when using fast-export/fast-import. If you can send us your esport package, I will try to debug it.But I think the initially reported issue in this ticket was a problem with special characters in branch names, label names and owner name, right? Is git fast-export replacing these special characters by the "-" character? PD: If you are migrating from git to Plastic, you may find useful the GitSync feature: https://www.plasticscm.com/documentation/gitsync/plastic-scm-version-control-gitsync-guide.shtml Regards, Carlos. Link to comment Share on other sites More sharing options...
Johan Ung Posted July 13, 2017 Report Share Posted July 13, 2017 GitSync handles utf8 file names very well but unfortunately I get a crash in one of my repos ( ) Git fast-export encodes eg. the character ä as \303\244 I will send you a pm with link to my fast-export dump, thanks. Link to comment Share on other sites More sharing options...
Johan Ung Posted July 13, 2017 Report Share Posted July 13, 2017 Puh, no need to hurry on this issue @calbzam. I finally managed to convert the octal notation to normal utf8 hex notation. Now I can continue with my migration to plastic. Link to comment Share on other sites More sharing options...
calbzam Posted July 14, 2017 Report Share Posted July 14, 2017 Thanks for the update! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.