Does it copies the files from server to agent or does it ask the agent to checkout the sources from version control at particular version?
Neither. For all repositories except mercurial, the repository is checked out on the Server and committed to a cache (a mercurial repo). The cache is cloned to the agents, and the agent exports the source into the workspace using the repository rules. For mercurial repositories, the server clones it, and then the agents clone from the server, everything else is the same.
This system is ok if the files were in FileSystem (not in any specific VCS). When the repository is already in a VCS why is it required to recreate another repository? I think you could consider this.
We’re not about to change this, what is there now is the result of 2 years of R&D on how to do this in an efficient and performant manner. Sorry, we will not reconsider just because you say we should.
Without caching the source, it would require that the all agent machines have the version control client (all of them) installed, and that the agents have access to the version control server (which may not be the case if the agents are in the cloud). Our design does not have nearly the performance impact that people would think… most of the time, getting the changes to the agents is extremely efficient (think pulling a revision from mercurial or git).
I was also thinking about the performance issues. As you say that there will no performance issues, then I will give a try.
Thanks a lot for quick response.
You might also want to take a look at http://wiki.finalbuilder.com/display/continua/Repository+Rules
You can use the Repository rules to limit which source gets check out into the build workspace, or if stages to do not need the source code you can remove the default rule to stop the source being checked out (for example if your Test stage only needs the binaries produced in the build state).