Comments on “ Source Control Strategies for Frameworks ”

Source Control Strategies for Frameworks

2008-08-15T15:00:10-04:00

Rob, take a look at Federico Cargnelutti’s recent article, Scalable and Flexible Directory Structure for Web Applications , if you haven’t already. He proposes and illustrates something similar to what Kyril and Peter suggest (mapping/symlinks).

Source Control Strategies for Frameworks

2008-07-21T17:21:58-04:00

Rob, I think that for Cake in particular, you’d want to version everything that comes with the default app/ directory, since even the files that you don’t end up modifying still pertain meaning in regards to your applications properties. For example, even if you don’t have any routes or inflections set up now, I think it’s a much better reflection of that fact to have an empty “routes.php” or “inflections.php” file, than having no file at all. It seems you’re already leaning in this direction, so I might just be wasting bytes here :)

One thing to consider if you’re worried about DRY is to version your cake/ directories separate from the app/ directories, and set cake/ as an external for each project-specific app/ folder you have.

Source Control Strategies for Frameworks

2008-07-17T11:24:54-04:00

@Peter –

Yeah, this is kind of what I had in mind except that this isn’t my own framework, of course. In your case, is “custom” code completely segregated or is it intermingled (to one degree or another) with the framework code? In the case of Cake, custom code is localized in a /app directory, but that directory also ships with code that may (or may not) be required for the application to work properly.

It’s that intermingling that is giving me pause since I’m not sure how best to represent only the intermingled custom code in source control.

Source Control Strategies for Frameworks

2008-07-17T10:20:39-04:00

With my in house framework, I version the framework in one repo and the projects in another (one repo per project). The projects have a mapping to the framework but not a copy of the code.

I handle the “changes in framework” issue with specific versioning, so if I make a change to the framework that affects any of the interfaces a project might call, I’ll install a new mapping to a new version of the framework, so I don’t have a mapping to /lightbase – it is to /lightbase2 or /lightbase3. That seems to work fairly well for me.

I don’t much like throwing the framework code into the project repo, but it does depend how many projects you do, how much control you have over the framework, how your build process is set up, how easily you can separate framework code from project code, etc.

Source Control Strategies for Frameworks

2008-07-17T10:05:05-04:00

@Dave –

I think frameworks – especially full stack frameworks – have the ability to rapidly evolve or devolve a language experience. I do like Cake, although I’m mostly working the engineering side. I haven’t had much opportunity to get into the nitty-gritty and really write code (which is why I’m using it for a side project now).

Okay, so two smart people have intelligently rationalized something that I was doing anyway. Guess I’ll just stick with it pending any dissenting opinions that are sufficiently well reasoned.

Source Control Strategies for Frameworks

2008-07-17T09:53:57-04:00

Rob, there also is a point to be made about framework versioning and backwards compatibility. With some frameworks that I have come across, updates down the line may break something in regards to backwards compat. I used to think that it was a good idea to have a server mapping for my frameworks. But what if I go to update that framework and suddenly I am left with solving whatever issues may arise across multiple applications rather than dealing with one at a time. I have since grown to consider a framework to be a part of the source code of each individual application and include it in the repo.

btw… cakephp is pretty sweet eh? Using it briefly made me realize that PHP development has really evolved a lot since I last dabbled with it!

Source Control Strategies for Frameworks

2008-07-17T07:58:05-04:00

Point made. I think it’s less about specific or explicit negative consequences and more about the “feeling” (excuse my digression into the warm and fuzzy) that storing it in my own source control doesn’t feel very DRY. Especially when the framework/project is open source I have direct access to its main repository.

The reason I’ve always just committed everything is to make my build process easier via consolidation and maybe that’s the right way to go. It just seemed like there might be a better way, so I thought I’d see if my accidental readership had any thoughts on the matter. :-)

Source Control Strategies for Frameworks

2008-07-17T00:54:54-04:00

Why do you want to do that? What negative consequences are there to storing the framework code outside of your source control? I see only positive consequences, especially ease of getting your project up and running on another person’s computer.