Same working folder for two repositories

[Tri]

Client + Server 3.07

We wish to move code from one repository to a new one. The working folder (C:\SolutionX) is mapped to the Vault $ / SolutionX folder in Vault, for both repositories.

When the code is added to the new repository, the $/SolutionX folder in the old repository is renamed and pinned.

Question: is there anything wrong for using the same working folder for different repositories (knowing that one is active and the other is read-only)?
Can you explain what happen for the baseline files, CacheMember_xxx files, _sgvault, _sgbak in such a situation?

Thanks in advance.

[sterwill]

The first thing I should say is that SourceGear did not design Vault to work in this way. Bad things may happen that we don't know about, because we haven't tested Vault in this configuration.

Files written to the _sgbak folder are never read again by Vault, and are given names that include time strings down to a fraction of a second. These files won't present any problems in your case.

The CacheMember_* files should be unaffected by this kind of operation. None of these files stores any detailed information about working folder files, they only store the working folder mappings.

This _sgvault/state file contains a mapping of Vault Object IDs to structures containing information about that Vault file (the name of the file, what kind of merge state it's in, what the date and time were at the last Get Latest, its CRC32 hash, etc.). Since this mapping is keyed off the file ID, a single file in the working folder that is mapped to two Vault servers (like your configuration) will be tracked separately for these servers. The baselines are also identifed by file ID (as well as Object Version ID), so they will remain apart, too. Things should work pretty well in this case, but because of how IDs are assigned, there's a chance that one day a file won't work at all like this.

The problem comes if the IDs collide. The Vault server gives its first file or folder an ID of 1, and any new files or folders created in any repository on that server will get the next higher integer value. If a working folder is mapped to two different Vault servers, and one file has the same IDs in both servers, the state information will be shared between the servers. This will cause bad things to happen (not terrible things, but the Vault client will get confused about statuses, etc.). If one server will be read-only for this folder, things will probably look funny for this folder when you're logged into that server, but as long as you don't make changes, things will look normal again when you switch to the writable server.

If you read carefully above, you'll notice that IDs are unique server-wide (not just repository-wide). This means that if you map the same working folder to different repositories on the same server, you won't have an ID collision. We still haven't fully tested this configuration, but I don't anticipate any big problems with it.

[Tri]

The first thing I should say is that SourceGear did not design Vault to work in this way. Bad things may happen that we don't know about, because we haven't tested Vault in this configuration.

We have no intention to work this way either. If there was a way to move Projects across repositories, we wouldn't bother with all this mechanism.

Yesterday, after a test on a small solution. After switching back and forth between repositories hooking to the same working folder. I saw 'Unknown' file status and have experienced a merge error in one of the local file. I didn't push the test further but there was definitely something to be careful about.

The reason we keep the same working folder for both repositories is during the transition time. Developers might need to go back and forth between repositories, mostly for searching labels & histories.

If the same working folder may lead to confusion and unexpected behaviour, can you advise a proper procedure to handle the situation? What do you think about:

1- Don't set working folder in the old repository. And set it to a temp folder only when we need to check out something.

2- Using two different working folders.

If you read carefully above, you'll notice that IDs are unique server-wide (not just repository-wide). This means that if you map the same working folder to different repositories on the same server, you won't have an ID collision. We still haven't fully tested this configuration, but I don't anticipate any big problems with it.

Does that mean, if a developer forgot to do the measure 1 or 2 mentioned above. And he/she connects to the old (read only) repository for some search / view / diff, there won't be any harm in the local files?

[sterwill]

Yesterday, after a test on a small solution. After switching back and forth between repositories hooking to the same working folder. I saw 'Unknown' file status and have experienced a merge error in one of the local file. I didn't push the test further but there was definitely something to be careful about.

The "Unknown" status is expected, if the files appearing as "Unknown" were never retrieved (via Get Latest or Get from history) for the repository you are currently using. Vault sees the file in the directory, which was put there because a Get Latest Version was done on "foo.cs" in the other repository. Since the file is known by a different ID in the new repository, Vault has no record of doing a Get for a file with that ID, and calls it "Unknown". If you perform a Get Latest Version in the repository you are currently using, and tell Vault to overwrite the file, the status should turn normal.

I would need more information about the merge problem to guess what could be causing the error, but I suspect it may be related to the Unknown files. If you're merging changes between these folders (into the new repository), I suggest using two different working folders (see below).

1- Don't set working folder in the old repository. And set it to a temp folder only when we need to check out something.

2- Using two different working folders.

Either of these alternatives will work. I would suggest using two different working folders. This is convenient because diff and merge tools that support recursive directory comparisons can be used to detect all differences between the trees. You can even run two Vault clients at once (connected to the two different repositories) while merging changes.

Does that mean, if a developer forgot to do the measure 1 or 2 mentioned above. And he/she connects to the old (read only) repository for some search / view / diff, there won't be any harm in the local files?

You should be safe, because the IDs won't conflict when all objects are on the same server. Operations that don't modify working folder data (like searching for files, viewing files, diffing files) should not cause problems with the files for the new repository.