fortress client on terminal server (application mode)

[scadaguy77]

Is the fortress client terminal services (application mode) compatible? Are there any special requirements or limitations when running in this environment?

The terminal server is running Windows2003.

[Beth]

We haven't tested this, but I know we have users who are using terminal server with our products. The key is to still have each user have their own login, working folder, and cache location. If any of those are set to the same for multiple users, there could be problems.

[scadaguy77]

Thank you for the reply.

I can understand the need to have different uses and cache location, but I am not too clear on the need for separate working folders. As I understand it, the working folder is where files are checked in/out. I want this to be common for all users working on the same repository/folder structure. Is this possible or will there be problems?

[Beth]

The working folder is the disk location the users perform their work. The cache is the portion that watches the working folders for changes and has some of the user settings. The cache doesn't know about the other caches though, and when one cache is updated by one user, the other caches are now out of date and have incorrect information. It's the correct information as far as what the cache was aware of. If one user checked out and made a change when everyone has the same working folder, then the status for everyone else would be Renegade because their caches didn't receive the checkout. The way to resolve Renegade is to either perform a Get Latest with overwrite, which would overwrite the first user's changes, or to perform a check out and check in which would either force the first user into a merge situation or perform an undo checkout which could reverse the version on disk (depends on the settings). To work in this fashion takes a lot of effort and tends to result in a lot of errors.

When each user has their own working folder, then their cache is aware when others check out a file, make changes, and check in the file. It can inform a user accurately if the version they have on disk is old or current. Also, you don't have to worry about a user accidentally overwriting another user's changes on disk. The ability to overwrite someone else's working area can lead to code that wasn't checked in being overwritten and could lead to one not realizing it was overwritten which would prevent a recovery of the overwritten code.

[scadaguy77]

I see. From what you say, the use of a common working folder will lead to constant version mismatches.

Let us assume that I have a single project folder with several files (> 100). A complete set of these files must be in a common folder to facilitate testing and easier development.

Should I maintain my own individual working folder with copies of ALL files? Other developers may need to review/interact with the files that I am currently working on during their own development process within the same project folder.

OR

Should I maintain my own individual working folder with only the files that are currently "checked out" and then shuffle the files between a "test" location and the working folder to perform development and testing?

One other question: What would happen if all users used the same login and therefore the same cache (on the terminal server) and working folder (on the terminal server)?

[Beth]

Shadow folders sound like the way to go for your situation. Whenever one checks in a change, that change can be replicated to another location by Fortress. That would allow each developer to have their own working copy on their machines and all current changes on the testing machine. This does require checking in the changes though.

Shadow folders are set up through the Fortress Admin web page under the repository you want to set them up for.

Would this fit your needs?

[scadaguy77]

Based on what you are saying, it would appear that I would need to keep a complete set of files in my working folder to properly utilize fortress capabilities. The need for a complete set is a requirement of the application as the files are interdependent. Though this is possible, it creates a lot of copies and the application itself would have to be configured specifically for each user to point to their working folder. Doing it this way would eliminate the need for a separate common location for the "test" files as each user would have their own set of "test" files.

The other piece of this puzzle is how to handle "publishing" the files to the production system, which in some cases consists of multiple locations. This could use the shadow folders mechanism, but would require stronger controls on what is "checked in" to prevent untested or unwanted updates from being published.

I hope I am not asking too many questions on this, but I am still not sure exactly how to implement fortress in this environment.

[Beth]

One other question: What would happen if all users used the same login and therefore the same cache (on the terminal server) and working folder (on the terminal server)?

I'm not sure. I would think it would depend on how many transactions are being sent to the cache at once. With one login, you can't track down who did what because it's all assigned to one user. We don't test with multiple Fortress clients open. The other thing is that this runs into a licensing issue. You would want to contact Sales to work that out to prevent any license violations.

Based on what you are saying, it would appear that I would need to keep a complete set of files in my working folder to properly utilize fortress capabilities

Fortress works best that way and that's how we test it.

The other piece of this puzzle is how to handle "publishing" the files to the production system, which in some cases consists of multiple locations. This could use the shadow folders mechanism, but would require stronger controls on what is "checked in" to prevent untested or unwanted updates from being published.

There's multiple ways to go about this.

• 1) You could use shadow folders, but shadow folders is automatic.
  2) You could use our Share All power toy to make a share of the project, then user our Pin All power toy to pin the share, then have the shadow folder point to the share instead. Then to publish, you would unpin the parts of the share you want pushed to production.
  3) You could use our deploy power toy.
  4) You could install a client at the location where you want the code deployed and use that client to manually perform a Get. You would script this also with our command-line client.
  5) If the server is internal, you could map a drive to your system and perform a Get to that mapped drive. Gets don't have to go to the working folder.

I'm sure there are other ways also that I am just not thinking of right now.

I hope I am not asking too many questions on this, but I am still not sure exactly how to implement fortress in this environment.

It's quite all right. That's what I'm here for. This will help other users as well.

[scadaguy77]

Back on this topic some years later...

Our current process/configuration is to have a single login to the terminal server that runs Fortress. This fortress client is setup to use the working folder as the location for state/baseline files and the user folder for the client cache files (which is the same for all "people" that use this repository). The actual people login to FORTRESS using their own userid, but to the Windows machine with a common login. If we maintain this procedure, will this properly track checkin/checkouts and file states for all FORTRESS users working on the same repository.

One other thing I noticed is that if one user has the working folder set as \\server\folder (where server is the local host where the fortress client is running) and another is using C:\folder, then file states seem to be different between FORTRESS users.

[Beth]

Thank you for the update.

Does each user have their own Fortress login, or are you using one Fortress login for all users?

[scadaguy77]

Each user has own FORTRESS login, but all use same WINDOWS login.

[Beth]

I think there's still the potential for some confusion to happen. In the cache, there should be an entry for each user logon, so each still has their own cache members. I have a screenshot of what it looks like in the cache when multiple users all log in on the same machine. It doesn't matter if their working folders are the same or not, there is a cache entry for each user. In each of those folders are different cache members.