Versioning question in team development

Posts   
 
    
Barry
User
Posts: 232
Joined: 17-Aug-2005
# Posted on: 05-Aug-2006 04:35:26   

Each team members of my team is responsible to develop a moudle of a system, all of them may change database structure according to their needs.

We are using vss to control version, they would create a new branch before they start to create new function, and they merge all modified files to main branch when they complete it. Therefore, they can develop their function independently in their branch and the main branch would keep all of their works.

However, llblgen project file is a binary file, it cannot be merge. The ways we do now is that check out llblgen project and entity classes in main branch and modify it, then create a sql script for database changes before check in, and send it to each members to update their database in order to prevent losing entities or fields next times they refresh the catelogs.

The main problem is that we need to build a release periodically, but some member may not finish their complex function, the release would not include files for those functions. But database and entities changes made by those members are checked in already, so I open llblgen project and rollback changes made by those members and generate files again before I build release.

I believe if llblgen project file is xml based, it would solve the problem easily, like the csproject file in vs.net, they can merge it to main branch when they check in, therefore it will not affect other members if they change database structure in their own branch, everyone can work independently and happily.

All members sharing the same llblgen project, all members are inter-dependent now, it is inefficient when developing a system in a team. Do you have any suggestions on handling this suitation?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 05-Aug-2006 09:57:03   

Please see: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=5794&HighLight=1 for a discussion about why it's not XML.

I really tried hard to make it XML, but I ended up with a reference-filled XML structure like the SOAP formatter generates as well. This too isn't versionable, as every version is unique.

Internally the project elements now do have a version ID and creation data, last changed date etc. This creates the ability to create a version merger later on.

If the db schema changes, the lgp file should change as well. So if you use this: - modify the schema - verify that the schema change is OK - update the LLBLGen Pro project - provide the developers with new lgp file and schema.

after all: merging them later on IS also very inefficient, because db schema merges aren't as simple as code merges.

A 'merge' of different versions of an XML file is also very unlikely, the thing is that with these kind of data-structures like o/r mappings, the main goal of the data is to couple one element to another. These elements are defined in the same xml file, but the mapping thus means references. multiple references to the same element thus results in special tags, which means that as soon as that happens, you can't merge the XML anymore with an older version.

Frans Bouma | Lead developer LLBLGen Pro
Barry
User
Posts: 232
Joined: 17-Aug-2005
# Posted on: 05-Aug-2006 13:17:18   

Oh.... I see your points.

And I've another question about the project file. My project file is 8MB large now, it takes over 10 minutes when I check in it to vss. The most terrible issue is that when other members get latest version from vss, and the project files is corrupted sometimes. frowning

I've other large binary files on vss too, like photoshop graphic files and zip files, but those file only takes a few seconds to check in, and they never corrupt after check in.

Do u have any ideas about this issue?!

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 05-Aug-2006 14:17:56   

VSS doesn't version binary files, it simply copies them. This means that if you need versioning control, simply use a backup system.

I'd also drop VSS for something reliable, like Vault or Subversion. Both support 'shelving' (I maybe made a typo there), which is the feature you described: create a branch, add features there, and when it's done, you merge it back into the main trunk.

VSS isn't reliable, I'd drop it a.s.a.p. if I were you. Sourcegear's Vault has a nice migration plan for VSS users, so it will be rather painless to migrate for example (you can try it out for free first)

Version control is mainly about scheduling work. The better work is scheduled, the more efficient version control systems work. Sometimes people simply do things without scheduling and rely on the merging capabilities of the system. This might be working for some situations, but it will also be a potential problem later on and will always take time, especially when conflicts have to be resolved which could have been avoided with proper work scheduling.

About your large project file: if you have a lot of stored procedures, you could opt for 2 projects: one with the stored procedures and one with the rest. This will keep the projects smaller, as the stored proc meta-data often makes .lgp files rather big.

Frans Bouma | Lead developer LLBLGen Pro
benles
User
Posts: 62
Joined: 02-May-2005
# Posted on: 26-Sep-2006 18:40:33   

Otis wrote:

I really tried hard to make it XML, but I ended up with a reference-filled XML structure like the SOAP formatter generates as well. This too isn't versionable, as every version is unique.

Can you give an example of a reference? Do you mean relationships through foreign keys and links?

I imagine a format like this:

<catalog> ... db connection & catalog selection info... </catalog> <entities> <entity name="Customer" dataname="tblCustomers"> <fields> <field name="Name" dataname="CustomerName" /> </fields> </entity>

</entnties>

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 26-Sep-2006 19:23:20   

Customer entity has relation object, which references Order and Customer, and contains a field from Customer and a field from Order.

If you serialize that to XML, you have a choice: either use names or use object references. If you use names to identify objects. It's actually not that important: if a name is changed in the large pile of xml, it will fall apart.

You'll end up via the customer at the order entity, which has a relation with employee. So you serialize that too. Back to customer, which also has a relation with employee. But you've already done that one. If you're using names, you'll get a duplicate definition of employee in the xml, which will simply explode (as employee has a relation with order, but you've already done that one, so you've to emit a marker instead of the order entity again, etc. ). So you'll end up with a single set of xml blocks, one for each object in the object graph. Then in the xml which defines the graph, you point to these blocks, exactly how soap xml looks like when it's written by the soapformatter.

Needless to say: one reference has to corrupt and everything falls apart. This isn't a nhibernate mapping file which falls apart at runtime of your app because some mapping is screwed up, this has to be rebuild into an object graph WITH meta-data from the db, so it's really much more interconnected.

Frans Bouma | Lead developer LLBLGen Pro