An idea for shared working folders
Moderator: SourceGear
-
- Posts: 12
- Joined: Mon Apr 06, 2009 3:12 pm
An idea for shared working folders
As has been documented since version 3.5.0, Vault does not support the mapping of the same working folder to two different items in a single Repository.
"The following repository path is already assigned to this working folder: "
However, I did discover that Vault does not differentiate between a physical folder and a junction point. Thus, I was able to create a junction point, C:\Source\ClientXYZ, pointing to C:\Source\BaseClient and then map one project to C:\Source\BaseClient\ and another project to C:\Source\ClientXYZ (both projects are in the same Repository).
reference: Junction by Sysinternals http://technet.microsoft.com/en-us/sysi ... 96768.aspx
What do you think??
I have donned my flame-retardant briefs so please, do not hold back in your response. My purpose for throwing this idea out there is to elicit additional information relating to the manner in which Vault tracks working folders and their contents. If it happens to spur thinking about how it might be modified to accommodate the need to support shared working folders, then I consider it a bonus.
And, unfortunately, until we can map the same working folder to multiple projects within a single Repository (or we land a huge $$$ deal and can rearchitect our system) we cannot migrate off VSS. Which means, my hopes to switch to Vault have been dashed.
Thanks for reading,
Eric
P.S. When I proposed the use of junctions, one of my colleagues replied, "I can see Eric Sink's response now..."
"The following repository path is already assigned to this working folder: "
However, I did discover that Vault does not differentiate between a physical folder and a junction point. Thus, I was able to create a junction point, C:\Source\ClientXYZ, pointing to C:\Source\BaseClient and then map one project to C:\Source\BaseClient\ and another project to C:\Source\ClientXYZ (both projects are in the same Repository).
reference: Junction by Sysinternals http://technet.microsoft.com/en-us/sysi ... 96768.aspx
What do you think??
I have donned my flame-retardant briefs so please, do not hold back in your response. My purpose for throwing this idea out there is to elicit additional information relating to the manner in which Vault tracks working folders and their contents. If it happens to spur thinking about how it might be modified to accommodate the need to support shared working folders, then I consider it a bonus.
And, unfortunately, until we can map the same working folder to multiple projects within a single Repository (or we land a huge $$$ deal and can rearchitect our system) we cannot migrate off VSS. Which means, my hopes to switch to Vault have been dashed.
Thanks for reading,
Eric
P.S. When I proposed the use of junctions, one of my colleagues replied, "I can see Eric Sink's response now..."
Re: An idea for shared working folders
Eric,
Thanks for the idea. Since this issue can potentially cause loss of working folder data, my stance on the issue is "Vault must disallow this." That being said, if people go out of their way to do something somewhat dangerous, that's fine, as long as they know that they're assuming the risk. It's the difference between having cars that explode when you drive them and stuntmen who drive flaming cars.
Thanks for the idea. Since this issue can potentially cause loss of working folder data, my stance on the issue is "Vault must disallow this." That being said, if people go out of their way to do something somewhat dangerous, that's fine, as long as they know that they're assuming the risk. It's the difference between having cars that explode when you drive them and stuntmen who drive flaming cars.
Subscribe to the Fortress/Vault blog
-
- Posts: 12
- Joined: Mon Apr 06, 2009 3:12 pm
Re: An idea for shared working folders
Thanks for the reply, Jeremy.
I suppose the underlying question in my original post is as follows:
"Does the Vault mechanism for tracking working folders depend upon the named path or the contents within the folder?"
It is possible (and apparently legal and supported by SourceGear) to set working folders which overlap. For example:
Vault:
$/
+-Base/
|
+-------/Scripts
|
+-Client/
|
+-------/Scripts
I can assign C:\Base\ as the working folder for $/Base which will cause $/Base/Scripts to inherit the working folder C:\Base\Scripts\. I can also set the working folder for $/Client/Scripts explicitly to C:\Base\Scripts and Vault doesn't complain.
Surely, based on this issue existing since v3.5.0, Vault's internal mechanisms work in such a way as to avoid the crashing and burning which would happen if both /Scripts projects were explicitly assigned C:\Base\Scripts. And, if that is the case, is it safe to conclude that Vault's internal mechanisms for tracking working folders and their contents are keyed by some explicitly stated folder name and thus use of junctions would avoid the aforementioned crashing and burning?
Make sense?
I suppose the underlying question in my original post is as follows:
"Does the Vault mechanism for tracking working folders depend upon the named path or the contents within the folder?"
It is possible (and apparently legal and supported by SourceGear) to set working folders which overlap. For example:
Vault:
$/
+-Base/
|
+-------/Scripts
|
+-Client/
|
+-------/Scripts
I can assign C:\Base\ as the working folder for $/Base which will cause $/Base/Scripts to inherit the working folder C:\Base\Scripts\. I can also set the working folder for $/Client/Scripts explicitly to C:\Base\Scripts and Vault doesn't complain.
Surely, based on this issue existing since v3.5.0, Vault's internal mechanisms work in such a way as to avoid the crashing and burning which would happen if both /Scripts projects were explicitly assigned C:\Base\Scripts. And, if that is the case, is it safe to conclude that Vault's internal mechanisms for tracking working folders and their contents are keyed by some explicitly stated folder name and thus use of junctions would avoid the aforementioned crashing and burning?
Make sense?
Re: An idea for shared working folders
You have pointed out a bug in our implementation of the overlap detection. Vault does not have any special code to make that case work, where the direct overlap case does not work. Neither technique of achieving overlapping working folders is "supported." Both are dangerous, but we accidentally left one of the techniques open, when we shut down the other.
Subscribe to the Fortress/Vault blog
-
- Posts: 12
- Joined: Mon Apr 06, 2009 3:12 pm
Re: An idea for shared working folders
Hi Jeremy!
Quick question - although what was described earlier in the thread is "against support" am I correct in understanding that we can point different projects in DIFFERENT repositories to the same working folder?
Repository: Base
Repository: CustomerABC
Thanks!
Quick question - although what was described earlier in the thread is "against support" am I correct in understanding that we can point different projects in DIFFERENT repositories to the same working folder?
Repository: Base
Code: Select all
$/
|--Scripts/ (working folder C:\scripts)
Code: Select all
$/
|--Scripts/ (working folder C:\scripts)
Re: An idea for shared working folders
Yes, you can. It has all of the dangers of two folders in the same repository, but there is no way for the Vault client to detect and reject working folders from two different repositories.
Subscribe to the Fortress/Vault blog
-
- Posts: 12
- Joined: Mon Apr 06, 2009 3:12 pm
Re: An idea for shared working folders
Again, thanks Jeremy!
Based on the discussion here: http://support.sourcegear.com/viewtopic.php?t=4915 can you confirm that the "dangers of two folders in the same repository" are limited to possible errors on our part and not cache invalidation within the Vault client?
If I understand the situation discussed in the 4915 thread, the problems stemmed from the invalidation of Vault cache. Given that each repository has its own set of cache files (re: http://support.sourcegear.com/viewtopic.php?t=6), can we reasonably conclude that cache invalidation is not a concern when setting the same working folder to projects in different repositories?
I know, same question phrased slightly differently. Sometimes, I don't understand a problem until I say it a couple of different ways.
Thanks,
Eric
Based on the discussion here: http://support.sourcegear.com/viewtopic.php?t=4915 can you confirm that the "dangers of two folders in the same repository" are limited to possible errors on our part and not cache invalidation within the Vault client?
If I understand the situation discussed in the 4915 thread, the problems stemmed from the invalidation of Vault cache. Given that each repository has its own set of cache files (re: http://support.sourcegear.com/viewtopic.php?t=6), can we reasonably conclude that cache invalidation is not a concern when setting the same working folder to projects in different repositories?
I know, same question phrased slightly differently. Sometimes, I don't understand a problem until I say it a couple of different ways.
Thanks,
Eric
Re: An idea for shared working folders
Yes, if you have two separate repositories (and you're keeping your Working Folder State/Baseline files in the Client Cache Folder (look for Tools->Options->Local Files->Cache Location)), there is no chance for the cache files to invalidate each other.
Subscribe to the Fortress/Vault blog