I'm curious of the best way to handle source control with llblgen is. Right now I've got a solution folder that has the dbgeneric, dbspecific, the generated manager classes, and the llblgen project file under it. In order to refresh anything you need to check out the world, run the project, generate, and then check the hundreds of files back in. That works alright for one person but it doesn't seem to scale well for more than that when people start checking out partialled out entity classes, validators, etc.. Is there a more sane way to handle this scenario?

Obviously there's going to be a subset of items you really need to check out for any given refresh but it's not really obvious what they are from the checkout standpoint. In the ideal scenario llblgen would do the checkout of items it needed to modify similar to how studio does it but I'm not really expecting that anytime soon unless someone's done a plugin I'm not aware of. I think the participating entity subset will give you the things you need but there's not really a way from there to easily go and check them out without more time spent hunting through the projects to find those files than it would take to just check out everything. Is there a better approach?

I've pondered using the inherited entity model so that I could put my inherited custom code in a separate source controlled project and just leaving the generated code entirely outside of source control so that at any given point things could be refreshed without the pain of checking it out etc but that seems like it would have plenty of downsides as well. Surely there's got to be a better way?

Unfortunately there's no better way at this time.

We are using Perforce and slowly starting to integrate LLBL into our existing major app (hurrah!). Here's what we are doing:

1) Nothing under the gen folders is under source control. In fact I even excluded it from the Perforce workspace so we can't add anything even accidentally.

2) We have a Nant script (not got around to using MSBuild yet) for use on the command line. In there we have a section that invokes Perforce to check out the two project files and their vspcc files; run the command line LLBLGen generator; and finally revert any unchanged project/vspcc files; We switched off non-essential updates in LLBLGen such as writing datetimes to the projects and generated files and we added a tweak to the TaskPerformer** that creates/updates VS project files so that nothing is written to the file when the output would be identical. So if theres no material change to the project file, we don't even get the prompt anymore in visual studio to reload the project.

3) Partial classes are/will be contained (we only have a few so far) in a similar hierachy to that under the gen folder. e.g. EntityClasses etc. Plus we also have some classes at the same level as gen. All non-gen classes are under source control as usual.

4) When syncing to the head revision, we just need to run the Nant build script to ensure that all of the genned files are created/updated at thats it.

Cheers Simon

** The tweak to the task performer is mentioned in another recent thread and really is a handful of lines. Hopefully it will be incorporated in 2.6 anyway.

Thanks Simmon that was very helpful. I hadn't thought about trying to mix the source controlled and non source controlled files in the same project.

I've pondered turning off the generated date stamp in the files myself as sourcesafe is smart enough to avoid creating dummy versions if the file doesn't actually change but it just creates worthless entries if that's the only thing that does indeed change.

Wouldn't suppose you've also got a good solution for sharing modified templates out to other team members have you? I've thought about just putting the whole runtime directory under source control and just having people set their root to their program files dir (assuming they remember to get the latest version) or possibly trying to change the template bindings to point to a unc path (if that even works) but I haven't really come up with the best answer yet. I don't change the templates that often but all it takes is one missed tweak to cause chaos if someone else regens. Right now the team is small so it's not a huge issue but if we scale out I can imagine some pain trying to keep the templates in sync.

GizmoTN76 wrote:

Thanks Simmon that was very helpful. I hadn't thought about trying to mix the source controlled and non source controlled files in the same project.

I've pondered turning off the generated date stamp in the files myself as sourcesafe is smart enough to avoid creating dummy versions if the file doesn't actually change but it just creates worthless entries if that's the only thing that does indeed change.

Wouldn't suppose you've also got a good solution for sharing modified templates out to other team members have you? I've thought about just putting the whole runtime directory under source control and just having people set their root to their program files dir (assuming they remember to get the latest version) or possibly trying to change the template bindings to point to a unc path (if that even works) but I haven't really come up with the best answer yet. I don't change the templates that often but all it takes is one missed tweak to cause chaos if someone else regens. Right now the team is small so it's not a huge issue but if we scale out I can imagine some pain trying to keep the templates in sync.

We've been pretty determined to ensure that we don't modify anything that comes out of the box for the very reasons you mention and Kudos to Frans for his designs which allow this to happen. We don't have very much custom stuff at the moment but the layout described below should allow us to do any customizations in the future without modifying anything more.

Here's what we have currently (YMMV):-

Our project is called "BPOSS" and lets call our root folder XXX. XXX\BPOSS.lgp

We have created folder for all custom items as follows:- XXX\LLBLGen.Pro.Custom\TaskPerformers XXX\LLBLGen.Pro.Custom\Tasks XXX\LLBLGen.Pro.Custom\Templates XXX\LLBLGen.Pro.Custom\TypeConverters

In the Project specific properties, we have added relative entries to the Additionalxxx entries.

.\LLBLGen.Pro.Custom\TaskPerformers .\LLBLGen.Pro.Custom\Tasks .\LLBLGen.Pro.Custom\Templates .\LLBLGen.Pro.Custom\TypeConverters

In TaskPerformers, we have TaskPerformersAce.dll (we append all our customized stuff whether it be LLCoolJ or DevExpress or anything else with "Ace")

In Tasks, we have "BPOSS.tasks" and "BPOSS.Adapter.General2005.preset"

In Templates, we have "BPOSS.templatebindings" and "typedListAdapter.addition.template"

In TypedConverters, we have nothing currently.

Because these custom files are in addition to whatever comes out of the box, the priority settings in the BPOSS.lgp file mean they just get used in preference to the standard items.

Cheers Simon