Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Version Control
 

Pages: 1
LLBLGen Pro Runtime Framework
Version Control
Page:1/1 

  Print all messages in this thread  
Poster Message
johnh
User



Location:
Australia
Joined on:
28-Sep-2003 22:50:14
Posted:
21 posts
# Posted on: 03-Oct-2003 00:14:08.  
Do you have any advice on how to incorporate LLBLGen(erated) code into source control for team use. Should we just use the same techniques as we use for normal code?
  Top
bonder
User



Location:

Joined on:
23-Sep-2003 05:05:17
Posted:
36 posts
# Posted on: 03-Oct-2003 04:32:36.  
johnh wrote:
Do you have any advice on how to incorporate LLBLGen(erated) code into source control for team use. Should we just use the same techniques as we use for normal code?


I'd be interested in this as well, although it seems to me that since LLBLGen Pro emits pure .net code, that yes, you should check it in and out of source control as needed.

I've just come off a project where we used DeKlarit, and you'd go crazy trying to figure out how to source control all of the various artifacts, because it creates and updates files even when all you do it open the solution! Angry

Anyway, just thought I'd chime in on this!

--Bruce


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37409 posts
# Posted on: 03-Oct-2003 10:49:57.  
johnh wrote:
Do you have any advice on how to incorporate LLBLGen(erated) code into source control for team use. Should we just use the same techniques as we use for normal code?

It really depends. One of my testprojects was changed so often (3-10 times a day), sourcesafe went bezerk of all the changes it had to log. This can really increase your sourcecontrol database a lot. Because it is generated code, it really doesn't matter if the source files get removed, you re-generate them again and you'll be fine. I'd store the .lgp files somewhere safe, perhaps in sourcecontrol to be sure you have a backup copy somewhere (and make backups of course, daily).

When you do not have a lot of changes (say once a week) in your generated code, or when you are using the two-class scenario and you're adding code to the generated files, it is recommended you place the complete sourcetree of the generated code in sourcecontrol and handle it like any other project.

A third option would be that you keep a separate solution with the generated code, compile that and reference the build result from that solution from your actual project. That will keep your other projects a little smaller.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37409 posts
# Posted on: 03-Oct-2003 10:51:04.  
bonder wrote:
I've just come off a project where we used DeKlarit, and you'd go crazy trying to figure out how to source control all of the various artifacts, because it creates and updates files even when all you do it open the solution! Angry

Yeah, deklarit... never a dull moment Wink I'd like to see them migrating a 100+ table production database because someone added an entity Regular Smiley


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
bonder
User



Location:

Joined on:
23-Sep-2003 05:05:17
Posted:
36 posts
# Posted on: 06-Oct-2003 04:15:45.  
Otis wrote:

Yeah, deklarit... never a dull moment Wink I'd like to see them migrating a 100+ table production database because someone added an entity Regular Smiley


It's too bad, too, because I like a lot of what they are trying to do. It just doesn't work as well as it should...

--Bruce
  Top
MattWoberts
User



Location:
Lancaster, UK
Joined on:
08-Apr-2004 10:24:31
Posted:
497 posts
# Posted on: 13-Jul-2004 15:06:19.  
Hi.

Just to bring this topic back into life...

I have added the generated code to sourcesafe, the gen'd projects are part of my "Solution" file I have created. The problem I am having is that the project, being part of the solution and of sourcesafe, has all the extra "gubbins" in it, and when I re-generate the code, my project file is re-gen'd and loses its sourcecontrol stuff.

Hmmm, should I just not allow it to change the project file when I re-gen?






Matt  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37409 posts
# Posted on: 13-Jul-2004 15:40:47.  
Matt, do you use v1.0.2004.1 or an older version, as the 1.0.2004.1 version alters the project file, not overwriting it, which means that the SCC stuff is preserved (the 4 attributes)
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
MattWoberts
User



Location:
Lancaster, UK
Joined on:
08-Apr-2004 10:24:31
Posted:
497 posts
# Posted on: 13-Jul-2004 16:59:00.  
Ah, I think I must have been using the old prototype when I looked into this! We are using the new one, and I have just checked and the project source control info is persisted! Thanks!



Matt  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37409 posts
# Posted on: 13-Jul-2004 17:17:33.  
Cool Cool Regular Smiley Thanks for the update.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.