Leaderboard

Merge conflicts happen whether or not the team is using branches or all developing on a single branch. If there are never any conflicts then it doesn't make much difference if you use branches or not. If there are conflicts then they can be a massive problem on long lived branches. But if there are no branches then they are also a massive problem. Often developments are in flux. Devs try something. Realise it was the wrong idea. Try something else, and so on. If this happens without branches then everyone has to deal with the conflicts over and over again. That's more work. Well managed branches make this easier. There never are magic bullet solutions for tough problems like this. You have to keep an open mind and do what works best for their teams.

Main issue with branches are merge conflicts. They tend to get worse with time because more code is added and there is potentially more conflict. So naturally, if you have short lived branches there is less possibility for conflicts to emerge. Also continuous delivery focuses on making small incremental changes (which is not always possible) so making small features that don't span across too much code (files) tend to be easily mergeable. Having said that, the lifetime alone actually means nothing. Nor the number of branches. First, you can easily shoot yourself in the foot with the branch old just a few hours, if you change some "hard" to merge file - think something like dproj file. On iOS, macOS that would be storyboards - you don't even need multiple developers to make a mess. So for some types of files, you will need to have specific instructions about who and how can change them without causing issues. Next, it is not how long branch lives, but whether you keep it up to date with other development. If you have branch and you merge it after a year, of course there will be trouble, but not because the branch is year old, but because you didn't keep it up. The most important rule is don't merge, rebase and rebase often. Not only that keeps history cleaner, but you will also have less conflicts - most of the time there will be none or they will be simple to resolve. And of course, in larger teams there has to be some coordination between what is done and when. It makes no sense to start some large refactoring in one part of the code few days before another large refactoring in overlapping area of the code is finished. It is better to wait than waste time on merging.

Image32 is a 2D graphics library written entirely in Delphi Pascal. It provides an extensive range of image manipulation functions and includes a polygon renderer that supports a wide range of filling options. Documentation: http://www.angusj.com/delphi/image32/Docs/_Body.htm Examples: http://www.angusj.com/delphi/image32/Docs/Examples.htm Download: https://sourceforge.net/projects/image32/

You don't need mac to compile units. Just use command line compiler to compile this unit: unit def; interface implementation {$if defined(MACOS)} {$message hint 'MACOS defined'} {$endif} end.

I have not heard of doing that. Why would you want to do that? Have you a specific reason?

That's correct. When you install a package in a project, it first looks in the package cache (typically %APPDATA%\.dpm\packages - can be changed by the DPMPACKAGECACHE env variable) If the package is there then that is used, otherwise it (and any missing dependencies) is downloaded from the registered package sources into the package source. Then using some msbuild variables the package and it's dependencies are added to the project's search path This is an example from the dpm ide plugin for 10.4 <PropertyGroup> <DPMCompiler>10.4</DPMCompiler> <DPMCache Condition="'$(DPMCache)' == ''">$(APPDATA)\.dpm\packages</DPMCache> <DPM>$(DPMCache)\$(DPMCompiler)\$(Platform)</DPM> <DPMSearch Condition="'$(Platform)'=='Win32'">$(DPM)\VSoft.VirtualListView\0.3.0-rc8\lib;$(DPM)\VSoft.Uri\0.1.1\lib;$(DPM)\VSoft.SemanticVersion\0.2.2\lib;$(DPM)\VSoft.JsonDataObjects\0.1.1\lib;$(DPM)\VSoft.HttpClient\0.2.4\lib;$(DPM)\VSoft.CancellationToken\0.0.3\lib;$(DPM)\Gabr42.OmniThreadLibrary\3.7.8\lib;$(DPM)\VSoft.Awaitable\0.2.1\lib;$(DPM)\VSoft.AntPatterns\0.1.1\lib;$(DPM)\Spring4D.Extensions\2.0.0-dev7\lib;$(DPM)\Spring4D.Base\2.0.0-dev7\lib;$(DPM)\Spring4D.Core\2.0.0-dev7\lib;</DPMSearch> </PropertyGroup> Then the DPMSearch variable is added to the project search path <PropertyGroup Condition="'$(Base)'!=''"> <DCC_UnitSearchPath>$(DPMSearch);$(DCC_UnitSearchPath)</DCC_UnitSearchPath> </PropertyGroup> and lastly the package references are stored in the dproj so they can be restored (if missing) next time you open the project <ProjectExtensions> <DPM> <PackageReference id="Spring4D.Core" platform="Win32" version="2.0.0-dev7"> <PackageReference id="Spring4D.Base" platform="Win32" version="2.0.0-dev7" range="[2.0.0-dev7,]"/> </PackageReference> <PackageReference id="Spring4D.Extensions" platform="Win32" version="2.0.0-dev7"> <PackageReference id="Spring4D.Base" platform="Win32" version="2.0.0-dev7" range="[2.0.0-dev7,]"/> </PackageReference> <PackageReference id="VSoft.AntPatterns" platform="Win32" version="0.1.1"/> <PackageReference id="VSoft.Awaitable" platform="Win32" version="0.2.1"> <PackageReference id="Gabr42.OmniThreadLibrary" platform="Win32" version="3.7.8" range="[3.7.8,]"/> <PackageReference id="VSoft.CancellationToken" platform="Win32" version="0.0.3" range="[0.0.3,]"/> </PackageReference> <PackageReference id="VSoft.HttpClient" platform="Win32" version="0.2.4"> <PackageReference id="VSoft.CancellationToken" platform="Win32" version="0.0.3" range="[0.0.3,]"/> </PackageReference> <PackageReference id="VSoft.JsonDataObjects" platform="Win32" version="0.1.1"/> <PackageReference id="VSoft.SemanticVersion" platform="Win32" version="0.2.2"/> <PackageReference id="VSoft.Uri" platform="Win32" version="0.1.1"/> <PackageReference id="VSoft.VirtualListView" platform="Win32" version="0.3.0-rc8"/> </DPM> </ProjectExtensions> Of course I have simplified the description above, there's a lot more to it but that is the basics. I'm currently working on project group support (made some good progress today) and then design time component support.

The reality is that most people don't modify packages, they just use them. As for packages being global, well that's one of my pet peeves - because I work on different projects or versions of projects that use different versions of a package - can't do that is packages are global - at least not without a lot of hassle. That's something I working to resolve in my package manager. The cool thing about any package manager is that it's optional - you can choose to use it or not, or use it for some packages and reference others manually like before.