I'm currently evaluating PlastiSCM. One of our evaluation tasks is to test migration from our SVN repository to Plastic. We want to migrate our trunk only since the branch structure and information is somewhat broken.
I was able to migrate to git with git svn. I fast exported the git repo with -C -M parameters. The import into PlasticSCM succeeded. However, when checking out \master on the imported Plastic Repo, the client complains about missing files. These files don't show up in the "Items" list in the Client.
The filenames which have issues contain octal escape sequences. It turned out that these file names have got german umlaute (ä, ö, ü) in them. I was testing git fast import of the exported stream. Git is able to handle theses filenames correctly.
After some digging I found this aged thread: Fast export/import issues. I've linked to a post telling about the octal coding issue. The thread is actually adressing TFS conversion issues in general.
One author claims to have a script which recodes octal coded characters into an encoding which can be read by PlasticSCM fast import. However, the script is not provided.
Has anyone encountered this problem as well? How could a solution look like? I can't imagine I'm the only one having this problem, especially because Plastic is developed in Spain where non-english characters should encounter quite frequently. I wonder whether this issues is known and tracked by the Plastic SCM development team.
Related
Why is it that when I try to view a commit that has changes to a RC file it says:
I can use TortoiseGit on my PC with the same commit and view it as a text file, which is what I expected. But not online with BitBucket.
The reason for this is the file encoding: UCS-2 LE BOM (a Microsoft version of UTF-16).
There is currently no fix, as even git diff only supports UTF-8. (Tortoise uses an own diff tool.) The workaround is to change file encoding before commit / after checkout, but I don't think that is suitable on the long run. In the meantime, one can only hope that Atlassian will provide UCS-2 support for Bitbucket Server.
I've been doing some tests, taking my code from git to TFS, using git-tf. Everything worked pretty much ok, except TFS thinks almost all my files are binary (discovered while finding the answer to this question). Actually, all UTF8 or UTF16 files are detected correctly, but those with an unspecified encoding (.cpp and .h files, mostly) are detected as binary.
Is there a way (some setting, or anything else) to convert from git to TFS and keep the correct encoding? Or, probably less ideal, to change the encoding of all the wrongly encoded ones in TFS?
If you have not set the type of a file, Git will determine it automatically and may treat as binary. With the .gitattributes file you can override its decision.
Tyr to add the diff attribute in the .gitattributes file:
*.cpp -diff
*.h -diff
What are the requirements for the vsn key in an Erlang application?
The Erlang/OTP documentation simply says:
Version number, a string. Defaults to "".
Is there any required ordering between versions? If I use a git SHA, will I still be able to use relups or appups?
To rephrase:
Is there anything in Erlang/OTP that requires a well-defined partial or total ordering in the vsn key?
The version can be any string, but with your idea I see 2 problems:
You will loose the ability to make comparison on version easily, I mean that you will need to maintain a catalog of all existing versions just to know if one version is older than an other (it should be accessible via git)
but as far as git works at the project level, you cannot know the SHA, and as the app file is part of the project, you cannot fill the version before commiting unless the app file is out of the git repository, which is not really interesting.
I am working on an idea which would require parsing through an SVN commit log, something that I know git svn is capable of doing, but I would like to do it via code. Is libgit2sharp able to support this, or does it only handle "real" git?
[...] something that I know git svn is capable of doing [...] Is libgit2sharp able to support this?
git svn features are not exposed by libgit2, the core library LibGit2Sharp relies on.
Although this might be implemented one day, it's not on the near future roadmap.
I am working on an idea which would require parsing through an SVN commit log
I'm not an expert in that field, but this looks like a common problem. Maybe re-implementing this parsing logic in C# wouldn't take that long.
.dproj files are essential for Delphi projects, so they have to be under version control.
These files are controlled by the IDE and also contain some information that is frequently changed, but totally irrelevant for version control.
For example: I change the start parameters of the application frequently (several times a day), but don't want to accidently commit the project file if only the part dealing with the start parameters has changed.
So how to deal with this situation?
A clean solution would be to take the file apart, but that isn't possible with the Delphi IDE AFAIK.
Can you ignore a specific part of a file?
We're using Subversion at the moment, but may migrate to Git soon.
In our case, it's rare for a developer to make a meaningful change to the .bdsproj, .dpr, .res files. So we reject the commit (pre-commit hook in subversion) unless special tags: [add project file] or [add res file] are present in the commit comment. This prevents "frivilous" changes to those files.
SVN/git cannot "know" which bits of the file are important, and translating what is important for you to commit or not into file "bits" would be difficult (especially when you don't know exactly how the information is structured within it). The most practical solution is to check the changes that have been made to the file and decide whether to commit them or not to the repository.
You can decide which bits of the file you want to commit with git. This is not, however, the automated process you seem to be looking for.
For the specific case of startparameters: the DDevExtentions plugin of the well known Andreas Hausladen allow for the start parameters be stored separetely of dproj file. See more details about DDevExtensions on his site.
EDIT: If I remember correctly, this feature was created just because he had that exact problem with start parameters and version control.
I would not save the .dproj files directly in version control, but rather provide a default file which should be renamed by the user to get the flawed Delphi working.
Use the --assume-unchanged option on git update-index <file> as described here and stackoverflow/what-is-assume-unchanged.
You could make simple aliases for the those who need it made simple.