need lots of help setting up source control

[GrandPixel]

I would really appreciate some help setting up an efficient method of using our source control system. We are using SourceSafe and SourceOffSite. We spend half of our time managing our source code, and have even lost customers over it in the past. We have 3 main customers for our primary project, and some of the code is shared between customers, but our product is customized for each. We are juggling the 3 customers, development and production, different version numbers, and a new revision of the product - copies of the repository everywhere. I can give more details about our setup, but I would like to know if someone is able and willing to help. New source control software is not an option, but I believe there is lots of room for improvement, even using SourceSafe.

[Beth]

We are certainly willing to help, but this will take many steps.

Let's start with understanding your current layout. I'm assuming it's something like:

$
|---Main Code Trunk
------|---Project 1
------|---Project 2
------|---Project 3
|---Customer 1
------|---Project 1 (files are branched or shared from Main)
------|---Project 2 (files are branched or shared from Main)
------|---Project 3 (files are branched or shared from Main)
|---Customer 2
------|---Project 1 (files are branched or shared from Main)
------|---Project 2 (files are branched or shared from Main)
------|---Project 3 (files are branched or shared from Main)

Does that sound about right?

[GrandPixel]

Actually we just had a meeting about all of this. I really wish I could have recorded it. Our system is a nightmare. Anyway, we actually have many repositories.

PRODUCT1_DEVELOPMENT
$/
|----Bugzilla
|----Docs
|----Learning
|----|----random stuff
|----Network
|----PRODUCT1
|----|----some random stuff
|----|----CUSTOMER1
|----|----|----PRODUCT1_SERVER
|----|----|----more documentation and random stuff
|----|----|----PRODUCT1_CLIENT
|----|----CUSTOMER2
...
|----|----CUSTOMER3
...
|----|----PRODUCT2
|----etc

PRODUCT1_CUSTOMER1_VERSIONx
$/
... SAME AS ABOVE

PRODUCT1_CUSTOMER2_VERSIONx
$/
... SAME AS ABOVE

PRODUCT1_CUSTOMER3_VERSIONx
$/
... SAME AS ABOVE

PRODUCT2_DEVELOPMENT
$/
...


Okay, so I should really just send you screenshots of our various trees so you can see them. Essentially what we do is for each product there is a development repository ($/ and everything underneath). When we build and deploy, we make a copy of it and label it "production version whatever built for whoever". So then whenever the customer finds a bug, we can fix the development version, and make the same changes in the production version that we deployed and rebuild the production version and redeploy. We don't make use of labels. According to everyone here, there is no way to do a "get" on a label from visual studio. I refuse to believe that... in computing, if something is useful, someone has figured out how to do it.


EDIT: Looking back at my post. You know what, our repositories are all random and it is confusing. I have not been able to understand them. If you want to see them let me know and I'll send you screenshots of the trees.

[Beth]

I think what you've sent currently helps.

You might check out Eric Sink's Source Control How To as a good starting point to give you a solid background to start from. What's going to be important to look at will be labels and branches. Eric uses Vault for his examples, but it's similar enough that the concepts should apply in a similar fashion.

In your case, if every customer is receiving customizations, then having a folder for each is good and makes it less confusing. Is there one baseline of code that doesn't have any customization?

When you say you have a lot of repositories, do you mean VSS databases or do you mean folders? Having a lot of VSS databases can be a good thing provided the division between them makes sense. For example, you might have Product 2 in it's own database, unless it shares code with Product 1. Does Product 2 share code with Product 1?

[GrandPixel]

What I mean is that we have multiple VSS databases. They are all the same code, just at different points in time. They are like "snapshots" so we can go back and fix bugs and redeploy without deploying all of our new unfinished code. I think that is where labels should come in, but supposedly Visual Studio will not perform a get on a label (I think this is somehow possible). Maybe branching after a build and creating a copy in a new folder would be better and simpler than copying the entire repository. I am not really sure what code is shared between the customers, or what is shared between products. Many features are the same, and the line between them is fuzzy to me.

A while back I read about half of Eric's guide. I think it is very good. Is there a pdf version that can be printed?

[Beth]

Unfortunately, there isn't a .pdf of the guide.

Do you ever have bug fixes that need to be done on a previous release? If so, then what is your method for getting the fix into the latest release?

What is the size on disk of your latest VSS database? Right-click the folder on disk that holds the VSS database and select properties and read the size from there.

We should try to narrow down the root issue. Is the problem finding things in the current tree? Is the problem getting bugs fixes into multiple versions? Is the problem finding which database information is in?

Explain a few of the exact issues you've seen.

[GrandPixel]

Yes, we do have to fix bugs from previous releases. To do this, our new plan is to fix the bug in the development code, and then manually duplicate the changes in the previous release production code. The reason we fix it in development first is that in the past, we would fix a bug on the release version and forget to change development, then the same bug would come back in the next release (upset customers). But in my opinion, the process of manually duplicating changes in 2 places is asking for trouble also.

The VSS database for development of our main product is about 2GB. We have about 10 copies of this and they are all between 1GB and 2GB. On top of that we have 12 other VSS databases (14GB combined) that we use for other projects or to store data and miscellaneous. Total size of our VSS databases then is about 28GB.

Our full backups have been about 22GB, or 11GB after compression. We have made a few changes to the VSS databases recently and our backup is currently 28GB uncompressed. We are trying to figure out an effective way to store our backups offsite regularly, but it's a lot of data to transfer. And much of the data is redundant from one VSS database to the next.

Yes, there is a problem finding things as well. There is often confusion about which VSS database we should connect to when working on this or that. This is probably more of an issue than finding things in the current tree.

[Beth]

To summarize, it sounds like 3 basic issues (feel free to correct me):

• 1) Making the same bug fix multiple times.
  2) Backups (space and transferal).
  3) Finding code.

Just as a side comment, my immediate gut reaction to this is to think that you need Fortress. Since you aren't looking for a product referral, I'll not try to convince you. That's just my personal thoughts on it.

Having multiple VSS databases has some benefits in that you are keeping your databases small. I think Microsoft recommends not going over 5 GB.

Before implementing any sweeping changes, you might create a copy of your main VSS database to try a few tests with to see what you think of working a little differently.

In order to do merging of branches, you would need to make use of your VSS client. Is that feasible? If so, I can think of a scenario that could potentially get you down to 1 database in the future and make your backups smaller.

As far as finding code, adding detailed comments on check-in goes a long way, or having some kind of integrated bug and task tracking can help as well.

[GrandPixel]

We use SourceOffSite for the VSS client. A single database for everything makes lots of sense to me, but I don't know if others would go along with it. What is the scenario you are thinking of?

We don't use comments, but I don't see how that would help find code. We "use" Bugzilla for bug and task tracking, but it is not at all easy to use, and no one really likes to use it.

[Beth]

What I was initially thinking was you performing Branches in your main code tree instead of copies, making fixes in the branches and then merging those fixes back to the trunk.

Your scenario is a little more complex though, because you need those changes to go to each customer version as well, I assume. If there needs to be more than one merge point than this wouldn't work well with VSS.

I'm not familiar with Bugzilla, so I can't comment on what you could or couldn't do with that.

I will agree you have a difficult situation here. VSS has some limitations that get in the way of working in a different way than you currently are. I don't think I have a good solution that will cover what you need in the context of your current software. SourceOffSite works only in the context of what VSS can do.

Here's what I see as your options:
1) Contact the VSS team to see if they have some recommendations. They will know their product better.
2) Review and consider a different product. Even though my answer on this has some obvious bias, I would recommend Fortress because:

• a) You can create multiple branches and perform multiple merges with fewer restrictions.
  b) You can tie your check-ins to bugs or work items, which helps explain why certain changes were performed.