All,

I am a freelancer working on a team with 3 other developers. The project is starting from the ground up and as such requires that each of us create new tables, stored procedures and views etc. We are using CVS for our version control. Everything is going well except that we keep running into a particular problem with the way we are using llblgen.

We store all our llblgen project files and generated classes in CVS. Whenever, any of us need to create a new typedlist or update the catalog schema we checkout of CVS, make the changes and then check it back in.

Unfortunately, we keep overwriting each other's llblgen changes. For example, if I create a new typed list and then update CVS that change is there. However, if another developer doesn't get my changes from CVS but in turn creates a new typed list and updates the CVS repository, my typelist changes (from the llblgen project's point of view) will be lost. This problem has happened enough times to where I am writing to you to see if you have any ideas about how to solve the problem.

I originally thought that we could just do CVS merges on the llblgen project file but then realized that it is stored as binary and so we couldn't do that.

Any and all ideas are greatly appreciated.

Thanks.

-- Rodney

The file is binary because the large amount of data would make a text representation too slow to load. The thing with these issues is that the only way to really fix it is to schedule work.

So if someone wants to make changes to the .lgp file, either plan it so one dedicated person makes the changes, or be sure you alter the file as the only person at that moment. CVS doesn't allow (as other edit and commit systems) single checkouts, so that might be a bit of a problem, but it's the same as with altering the database schema: it's best to have one person do it, or schedule the work so when someone is altering it, not another person is altering the data.

As not 2 or 3 people can alter a word doc or a jpg file at the same time, this is the same. Sourcecontrol systems allow you to get away with it on text files by offering merge capabilities, but that's not always working either (merge conflicts for example). A better scheduling of the work allows everyone to work in parallel without running into these 'real life concurrency problems'.

Thanks for the response. I think that we can do this.

-- Rodney