Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
1  
Sounds like a great way to justify expanding your support staff! –  Stephen Gross Dec 7 '11 at 15:51

2 Answers 2

up vote 7 down vote accepted

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.

share|improve this answer

IMO using different VCS at the same time just give you a headache from the maintenance standpoint. And also will make life of developers harder.

If your project histories are really separate from each other (different teams, branches, development cycle, etc.) I suggest to try to implement mechanism like svn externals or git submodules (TFS should have something similar). This approach worked well for us. Back-end developers are not concerned with UI and use their own tools. Main project tree has their branch defined as external, and front-end developers need not think too much about different dependencies when building their stuff.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.