how to clense the Old VSS crap and put it in the Vault?

[lwatson]

We have bought into the Vault and have it installed onsite

We use to use VS(un)safe and are looking to implement our source control on the vault product.

Rather than migrate our questionable VSS content to the Vault we are looking to simply clense the VSS crap from our solutions and then put it in the vault as if we were starting anew.

Our problems appear to be many and inconsistant.

Some items in some projects won't appear to check in ( We have looked at all the relevant Keep Items checked out settings ) Yet this seemingly persists.

Projects that are checked in seemingly lose their bindings on reopening them.

Projects/Solutions that have multiple subprojects in the vault tree done have those subprojects fethched from the server when attempting to open the project from inside VS via the Open from Source Control. If you get latest version from the vault client and select the working folder you can select to recurse over the project and get all the subs but then you might have a problem opening that in VS becaause of bindings issues like the one mentioned above.

One potential issue that our setup might have over everything I have read about this thing is that our IIS server is running at port 8080 rather than 80. We have to do this because we have webservices living inside our network on this IIS server and we use Apache for the internet facing part of our setup. On the apache server we port forward 8080 to the inside server. The isue is not the port forwarder however because inside our lan we get directly to the server at 8080 no forwarding is going on. If the thing won't work at 8080 then we have a problem.

Example server connection wouldd be LOCALHOST:8080 for thee admin tool runing on the server itself.

[dan]

Some questions:

Do you do an Open From Source Control every time you open VS, or just the first time a user wants to start using the project? Open From Source Control should be a one-time only operation. If you invoke it on a folder that already has files and bindings in it, it will cause binding problems.

In fact, if the user does an Open From Source Control and choose the working folder they used with SourceSafe, that might cause problems too - it should be a completely empty working folder that they start with. Otherwise, the file status would be Unknown, and files wouldn't checkin properly.

Another thing to do when things go haywire in the IDE client is to check the status of the files and their working folders in the Vault GUI standalone client. That sometimes offers clues as to what is happening.

The port issue shouldn't be a problem, but it might be good to verify whether the Vault GUI client has problems with the same operations as the IDE client.

[lwatson]

Lets take a typical scenario

We have a project that was in Sourc(Un)Safe.

There are 4 files in that project folder that represent some sourcecontrol stuff for the Old Source Safe. We remove these files.

We then make all files in the project directory writable ( Using windows exploder)

We then open the Project in the IDE.

We answer the dialogs about sourcecontrol stuff being out of wack and what not.

We have a project that is now apparently standing alone. We can continue to develop on it without source code control if we are in the mind to do so. In fact prior practice here was to do just that when we were making a branch then check the branch back in under a new project name into source (un) safe. The results are a mismash of stuff and thats why we did not want to to a VSS import we wanted to do source control right with the vault.

At any rate we now want to put the thing into source vault.

We go to add the soulution to source control.

Login, Select repository, Enter Project Name (Off of the ($) root ) (Made that mistake already).

It adds the thing just fine and usually all the items are checked in.

This is the point were some of our problems exist.

Hence my initial question about removing the source control stuff from the project initially. Is our trial and error findings of clensing the taint that is VSS from a perfectly good source code collection, doing the job?

[dan]

So, when the second user wants to use the source controlled project, what do they do?

What they should do is:

1. Bring up the IDE without loading any project
2. Do an Open From Source Control to a new working folder. Opening it to an existing working folder, even if it has become untainted, will cause problems. Vault doesn't recognize files it has not retrieved, and calls them Unknown, even if they match versions in the repository (this is a problem we are addressing in the next release).
3. After that, it should work fine. Don't do a second Open From Source Control after this on the same machine, because the bindings are setup at this point.

One other thing to note: Sometimes, the IDE thinks that a file that is writable on disk is actually checked out, even though it is not. You should check whether the files that are reported as checked out are really just writable. A Get Latest from Vault should mark them all read-only. Note that the Vault client does care whether a file is read-only or read-write the Visual Studio sometimes does.

[lwatson]

Ok..

That sounds good.

Tomorrow when all the folks are here we'll beat it up like that and see if some of the things are resolved.

Incidently I plugged into an outside lan port elsewhere in the building and the
port forwarding on our Linux firewall allows connection to the Vault just fine. SSL and everything. Thats wonderful since we are often scattered to the four winds here in the northeast...

Thanks for the info...