Labels and project dependencies

[ThomasC]

We have some fairly large web application solutions that have numerous shared libraries. Our repository structure looks something like:

Code: Select all

Libraries
   Lib1
   Lib2
   ...

Web Applications
   App1
   App2
   ...

In this scenario, both App1 and App2 have references to the library projects Lib1 and Lib2. We also have CruiseControl which nightly builds the applications and applies a label both the application folders and to the library folders. For example, we can look up the label history for Lib1 and find the labels App1_1.2.3.4, App2_1.2.3.4, App1_1.2.3.5 etc. The problem comes when we need to build a branch off one of the applications. For example, suppose I need to branch off App1_1.2.3.4. I can easily build that branch directly from the Web Applications/App1 folder and the appropriate label. However, how do I get my branch to include the versions of the child libraries that went with that application? Do I have to go through, library folder by library folder and pull the label for each one? That's a serious chore. Am I required to use something like shadow folders to ensure that I have a link to each library folder underneath each of my application folders?

How do other developers handle this problem of versioing the shared libraries along with their applications?

[lbauer]

Where will you put that branch? Under Web Applications? Somewhere else?

[ThomasC]

I can think of one of two solutions:
1. I "get" on a label and it overwrites into their same working folders with the version of the files across all folders that were part of the label.
2. I "get" into a separate folder root which maintains the same directory structure. I.e., if I wanted to make a branch off App1_1.2.3.4 and stuff in into a folder called "Foo", I'd end up with Foo\General Libraries\Lib1, Foo\General Libraries\Lib2, and Foo\Web Applications\App1

How do people deal with this problem now?

[lbauer]

For this to work properly, you really need a common directory for both Libraries and Web Apps:

$/My Apps
--- Libraries
----Web Apps.

Then you would branch and label at My Apps.

Another option might be branch Libraries at the version you want, and put that under the folder as Web apps.

You could also share Libraries, though any change to one of the shared directories would be reflected in the other shares.

[ThomasC]

For this to work properly, you really need a common directory for both Libraries and Web Apps:

If I use a common root folder, won't a label apply to everything in the root? I.e., to expand on your example:

Code: Select all

$/My Apps
   /Libraries
   /My Apps.
      /App1
      /App2
      /App3
      /App4

If I create a label at $/My Apps, won't it apply to all my applications. So, I do a get on App1_1.2.3.4, won't I get the snapshot of everything from $/My Apps on down at the time of the label? If the root folder were the root of the repository, in essence, each label would be a snapshot of the entire repository.

Another option might be branch Libraries at the version you want, and put that under the folder as Web apps.

I'm not sure I understand this option. Using the above repository structure, if I need to pull a branch on App1, where would the library folders go? Is the idea to physically relocate them in the branch underneath my app folder? Wouldn't that break the working folder in Vault?

You could also share Libraries, though any change to one of the shared directories would be reflected in the other shares.

This is kind of where I was going. Again, how do other people (including SourceGear) handle this idea of having multiple projects sharing multiple libraries?

[lbauer]

If the web app versions need different versions of the libraries, then sharing may not work, because all the shared links will be updated when files in one of the shares is updated.

You might be better off with branching. Branch Libraries at the version you want. You can even branch from history. The branch can go into the Web App folder or parent folder.

Regarding labels, yes you could label the parent folder and all the subfolders would be labeled as well.

But you could get just the subfolder that was labeled. You can use the Show Labels command on a subfolder and see the inherited label, and get just the labeled versions from the subfolder level.

[ThomasC]

If the web app versions need different versions of the libraries, then sharing may not work, because all the shared links will be updated when files in one of the shares is updated.

You might be better off with branching. Branch Libraries at the version you want. You can even branch from history. The branch can go into the Web App folder or parent folder.

Right now, the projects reference the library projects directly anyway. So, it is already the case that changes to the central libraries are seen by the various application projects. Generally, that's a good thing. The problem is in making a branch off a specific label. If the referenced projects are not physically underneath the parent web project in the repository, there doesn't seem to be a clean way of creating a branch which includes everything that was labeled (i.e., includes the referenced libraries).

Regarding labels, yes you could label the parent folder and all the subfolders would be labeled as well.
But you could get just the subfolder that was labeled. You can use the Show Labels command on a subfolder and see the inherited label, and get just the labeled versions from the subfolder level.

The problem here comes in having multiple web applications that reference multiple library projects folders in which the library project directories are not directly underneath each application's folder in the repository. It seems that the only way to pull a full solution based on a label is if there is a common parent folder to all of the assembly project folders in the solution and that leads back to using Shared Folders. It is either that, or manually branch folder by folder on the same label.