Discussion Forum for StarTeam Users
Posted by Avi Shmidman on June 21, 2001 at 05:09:01:
I have run into a number of difficulties and limitations regarding shared files in StarTeam. Perhaps I am misunderstanding StarTeam's overall paradigm for working with shared files. I will list below a brief summary of three issues we found with shared files; following that, I will grapple with the shared file paradigm which is missing here. Perhaps readers will suggest alternate paradigms for working with shared files.
1] Within any given view, our engineers check in their source files at the end of every day. These files are not tested or verified yet; but that's OK, since we use view labels to denote snapshots which are ready for testing and release. The "current" version of a view is work in progress.
This is all fine for non-shared files. But, with shared files, we cannot work this way, since other views will receive the work in progress. We want to be able to check in a file as work in progress, without it being automatically shared everywhere, until we note it as such.
2] A very similar issue arose regarding product components (I posted about this here once before). We have DLL files which are developed in their own view (since they are versioned separately), but then shared into the main product. We want the production level DLL to automatically be shared into the product, but not interim builds which are released for testing and so on.
3] Another issue, which I also posted about recently, regards control of the shared file. There are some files which are shared into a dozen or so different views. I don't want an engineer working on any one of the dozen views to accidentally check in a new version of the shared file. Rather, I want to ensure that the shared files are only updated deliberately, by certain privileged engineers.
** Paradigm Summary **
The three issues boil down to the following. I am looking for a method of sharing which
a] distinguishes between the original instance and the shared instances
b] shares a specific (but dynamic) version of a file.
(a) would address my third issue: it would allow me to specify that a given file, while shared to 12 different places, can only be updated at one.
(b) would address my first two issues. It would allow me to share a file based on a particular promotion state, for instance. Thus, I would be able to update the shared file in the original instance, without automatically updating all shared instances. But, in addition, when I want to update all shared instances, I would be able to simply change the promotion state of the original instance, and instantly all of the shared places would update.
StarTeam, however, seems to propose a different paradigm:
a] All shares are equal. There is no starteam concept, as far as I can tell, of the "original instance".
b] Shares are based on current version only. Unless they are branched; but if they are, they cannot be updated automatically anymore without adjusting the file properties of each share.
that is OK, because StarTeam manages two separate
Post a Followup