MSimon wrote:Versions are strictly controlled. All the tools for a version and all the code are cataloged. Including make files. Compilers. etc. Then you make them write only (effectively) except for authorized changes.
Before the first official build you can organize the project any way you want. After the first official build change becomes much harder. And the organization becomes more top down.
You would still have a central authoriative build repository which pulls changes from developers after their unit testing. For the build environment, Mecurial can apparently lock parts down - see "Repository Permissions" here
. At each release build the tool binaries could be fingerprinted with something like md5sum
to a log file to diff with previous versions.
From this article
I like this description:
So there is the appeal of distributed version control systems. Branching allows you to track individual changes in their own branch and “graduate” them to the trunk after they have been vetted. Not only that, if you want to test a fix in isolation from other trunk changes, the branch allows you to do this by implementing the fix on top of just the last released version of the code, without any interim work (vetted or not) to gum up the works.
Getting back to my point about branching being the regular mode of operation in this model, each repository in this case can be viewed as its own branch. The reason I say this is because each copy of the repository is not required to synchronize after a change is committed. In Subversion, once a commit is made, no other changes can be committed by other developers without them first updating their working copy and resolving any conflicts that arise. This means that, in Subversion, for a given directory path there is only ever one line of commits (barring discussion about explicit branches, which are different directory paths). Each subsequent commit contains all of the changes from every commit prior to it.
In a Distributed VCS, concurrent changes can be committed to the various developers’ separate repositories, and no communication happens between them unless the developers initiate it manually.
I take this to mean that its harder for developers to change-control their work-in-progress files without interuptions from other developers - and also that developers can parallel work on the same area of code and cross-test with each other before it hits the trunk and affects the rest of the team. [Disclaimer: I'm only familiar with this in-theory, not-in-practice]
BTW, I assume theydo currently us some sort of source versioning system. Do you know what is typically used?
In theory there is no difference between theory and practice, but in practice there is.