I've written a small VCL program using Delphi CE. I want to publish the source code incl. forms on Github but I'm not sure which parts are essential to include in the repository so that others can load it in their IDE and compile it.
I recommend you to use default .gitignore file for Delphi of Github. By this way you can be sure that all required files will be posted and all unnecessary files to compile will be excluded.
The file is here:
https://github.com/github/gitignore/blob/master/Delphi.gitignore
If you have an existing repository and want to add a gitignore file, have a look at here: Apply .gitignore on an existing repository
You can also exclude this files:
.~
*.dsm
*.ddp
*.map
*.rsm
*.dcu
*.tds
*.local
*.identcache
*.dsk
*.stat
*.tvsconfig
Exclude too the content of directories:
__history
__recovery
In addition to the other answers, some commonsense advice:
Put whatever minimum set of files you think you need into git
Download yourself (into a separate folder)
See if the project builds
If it fails, add the missing file(s) and repeat
Related
I have an issue with vs code and source control TFVC.
when I make any check-in to the server. any new folder is not uploaded right.
any idea?
TFVC
In general, I prefer not to let my project file know about the node_modules folder at all. And the projects load faster and I don't have to worry about the large commit messages in source control.
To achieve that we can Customize which files are ignored by version control
So, I agree with Daniel, in your scenario, if you mean you want to check in the node_modules folder and its sub-folders. Then you need to check if you have set the ignore rules in .tfignore file. If you set, just remove it.
UPDATE:
Based on OP's comment, as a workaround we can use Visual Studio to sync up the folder. (Check in the folder with VS, then sync to VS code)
Using Code Gear Delphi 2007 (don't know if it matter), each time a ".bpl" package is compiled, a ".~bpl" file is created too.
What are ".~bpl" files? Are those files required or is there a way to avoid their creation?
It's the backup of the previous copy of the BPL file, just like the .~pas files are backups of the .pas files and the .~dsk file is a previous copy of your desktop settings file and the .~dfm is a previous copy of your .dfm file.
There's no way to avoid their creation, but they're harmless. I'm not sure why they would concern you, but you can always create a post-build event in your project to delete them after a successful build.
I've been publishing my site regularly without too much trouble. But today I noticed that it won't overwrite existing .cshtml razor files with the new versions. I publish, look at the folder, and see the files are still out of date. If I delete the file and then publish, it will put the new version there. But if the file already exists it won't overwrite it and my production website is out of date. I tried doing the option 'delete files before publishing' but it gives me an access error that it can't delete folders. I tried deleting the entire folder but then I lose my .svn folders and it won't recognize version control.
Is there a way to force the Publish command to overwrite my .cshtml files with the latest version? (note: the dll files get overwritten fine)
Have you set the Copy to Output Directory to Copy Always?
I use Build Action = Content too.
Seems like Read-Only attribute is set on files, so they can't be overwritten. Check VS Output window for signs of errors.
Advice: Try to NOT include generated files (this also means folder with published files) in source control. VCS tools usually tend to lock-up files they work on.
Having .svn files on Test/Prod server is also not a good idea.
I have a big project written in Delphi and I want to manage its sources using Git. I created Git repository, which includes my application's sources and 3rd party components. All that stuff is automatically building using msbuild.
The biggest problem is RES files. Some of them are updated every time I rebuild my application, some are not. Some have *.rc sources, some don't. I can't ignore all res files (.gitignore) because without resources my project will fail to build. Also, I can't include res files - they change from build to build, I don't want to see them in diffs.
What do you do with your *.res files under Git? Any advices?
Welcome to the club. The application .res file in Delphi is a pain in the lower back for everybody using source control. You want to use auto-inc-buildnumber but it messes up your scource control.
What I have done is
split the icon and the version resources like this:
{$R *_icon.res}
{$R *._version.res}
disable auto inc of the buildnumber
add a pre-build event to the project that
increments the build number in a .ini file corresponding the project
generates a .rc file with the version info from the .ini file
compiles a .res file from the .rc file
add the *_icon.res file to source control, it never changes so this is safe
add the .ini file with the version info to source control, it is a text file so it is easy to diff
The tool I have written for generating the version .res file is free software, available here and also from OSDN
I keep my project RES files in git (those that match the name of the dpr).
I believe the only reason the project RES file would change every time you build is if you have increment build number set, which to me either means you need to keep the res in source control or you don't care about the build number so you should turn off that option.
I do also have RES files that I build from RC, which change every compile, so I have a gitignore for *.res and I then add git add -f project.res for the project RES files
By definition, RES files are compiled RC files. So ideally you should ignore all RES files and commit only RC changes. If it happened somehow that you don't have an RC source for some particular RES file, then add only this "orphan" RES file to git - such files shouldn't change from build to build (cause there is no RC file to generate them from). If for some strange reasons (Delphi, huh) such RES files do change, then you are doomed.
Bottom line: RES files are compilation targets - no different from other binaries (obj,exe,etc)
It's strongly advised to disable the "Auto increment build number" in the project settings, with any kind of version control system. This way it's 'safe' to add the .res files to the repository.
I have been searching for a long time for a way to auto-update the build number in the version info in the project's .res file, but the best thing is to update an extra .rc with the version info. In practice though, I generally update the build number to the current subversion revision number only right before the final build for a release of the binaries.
I don't know GIT, but under SVN I simply only "SVN ADD" the few that matter, and not the automatically generated ones. Since unversioned files are excluded from diffs, that's taken care off too then.
Could you:
ignore all .res files
generate the .res files that can be generate (compiling the resources script .rc files)
add only the .res files without .rc files to generate them: if you had specified in a .gitignore that they are to be ignored, then adding them is ok: they won't show up in the diff.
I have a multi-project solution being stored in TFS.
Each project has separate Debug/Release build configuration folder specified.
The main project's bin folder is "included" in source control because it contains some third party DLLs that are included in the repository.
Each reference is a "project" reference type as per MS/TFS best practices.
Every time I build the solution, VS/TFS copies all of the built dependencies for the main project into both the build configuration folder (debug/release), and the root bin folder. When the file appear in the root bin folder, they get added to source control (or if they were already there due to this same issue, checked out)
For now, I have removed the bin folder from source control, but this is less than ideal, because now each developer must maintain the local DLLs, rather than just getting them from source control.
My ideal solution would be to just use SVN instead of TFS, but I'm locked into this one.
What's the best practice in this scenario?
If you want to include binaries in your source control (and some people would burn you at the stake for doing so) I would do the following:
Create a "Binaries" folder inside the project
Copy the dependencies in there
Add references to those DLLS in that location
The project file will then contain relative paths to them, so you can safely include that directory in source control and have it work for all devs, without having to add your "bin" directory to source control.
After using the solution outlined in the above answer and comment, I've found that for some reason, one of the DLLs is not being copied to the bin folder when the solution is built. (Copy local is set to true for the reference.) The DLL is copied into the build configuration folder, but not the main bin folder. It is used in the application, so dependency checking should pick it up. As it is now, a runtime error occurs whenever code attempts to access this component (as would be expected with a missing DLL.
Any ideas?