Quick question:

Where does the catalog name actually get generated into the code?

I ask because we have two branches of development currently, and they hit different databases. Is there a certain set of generated code that I should exclude from merges?

Thanks,

Phil

Could you please explain a little further?

goose wrote:

Could you please explain a little further?

Yep, sorry if that wasn't clear.

When we merge two projects that use difference catalogs in the database (like "myProject" and "myProject-v2-Beta"), we end up having to regenerate the LLBL code for the branch that gets merged into (or use catalog overwriting).

I was wondering if there is a specific class or set of classes where this catalog name is stored, which we would then avoid merging.

We have workarounds (regenerating the code), but I just wanted to make sure we are following the best practice for merging LLBL code in separate branches.

Thanks, and let me know if that's still not clear.

Phil

this thread may help you.

http://llblgen.com/TinyForum/Messages.aspx?ThreadID=7006&HighLight=1

All persistence info is generated into the PersistenceInfoProvider class which is in the DBSpecificProject in adapter and in the HelperClasses folder in selfservicing

Otis wrote:

All persistence info is generated into the PersistenceInfoProvider class which is in the DBSpecificProject in adapter and in the HelperClasses folder in selfservicing

Awesome, thanks Frans.

Would you recommend NOT merging this file when maintaining projects with different databases, or simply regenerating the LLBL code for the project each time we merge?

I guess I could try it and see what happens.

Thanks,

Phil

I'm not sure I completely understand the concept of merging projects. But from what I understand so far, you should be using catalog names overwriting, that's the recommended way.