I am contemplating a few different techniques for organizing code for a larger web application. For this situation, the server runs some Microsoft solution (probably ASP.NET MVC or OpenRasta) and the client (JavaScript, CSS, etc.) will consume this. Traditionally in an MVC application, the controllers and models along with the client codebase all live in the same project/solution. Our current solutions use TFS for source control.I want to start using Sass and Compass for the front-end, which will require Ruby, and I would like to use git for the version control of the front-end and continue to use TFS for the server components. The problem I have is that in order for someone to run the solution, you would need to pull from both repositories, and I am not sure if that is reasonable.Would you attempt something like this? Can you think of a better way for the projects to be structured so that front-end is separated from back-end? If I have not explained this well enough I will be happy to elaborate.
Reasonable to use different version controls for different parts of a web application?
project structure
I would discourage this practice, and encourage a single unified version control (and larger configuration management) policy on a per-project basis.Any individual, at any point in time, should be easily able to recreate the project as it was in a particular moment of time, and splitting the project up into multiple version control systems makes this much more difficult, since you are dealing with commits, branching, and tagging in two systems instead of one.As far as separating the back-end from the front-end, a logical separation is fine, and doesn't require a separation in version control. If you are reusing the same components across multiple projects, consider a trunk and creating appropriate branches for specific changes that might be on a per-project or per-client basis.