I upgraded to 3.5 this past week, and have just discovered that I can no longer have du0licate working folders. My application I inherited relies upon all executables being in the same folder. I prefer not to have them all in one big folder as that is a nightmare! I have now reread the release notes and see it listed as a "fix" That would be why I missed it. I had no issues I needed fixed, so I didn't bother looking there. I personally don't see this as a "fix" but as a "feature change." It worked great for me that way, and never thought of it as "broke." Is there any chance to get this added back as an option? I REALLY don't want to move everything into one folder, and right now I have to continually remove the working folder and reset it everytime I open a project. Im not even sure what is going to happen when I need to have multiple projects open!
Brian
Duplicate Working Folders
Moderator: SourceGear
We have a feature request open to change that functionality and I will add your vote. With the way it was, there were lots of users with problems resulting from that.
In the meantime, one option is you can set a working folder at a higher level folder and select for the folders below it to inherit the working folder.
Another possibility, I think, is if there are only certain files and folders you set to that one is you can create a share to a new file in your repository of the things you will want in that working folder, and then set that share to the working folder you want.
In the meantime, one option is you can set a working folder at a higher level folder and select for the folders below it to inherit the working folder.
Another possibility, I think, is if there are only certain files and folders you set to that one is you can create a share to a new file in your repository of the things you will want in that working folder, and then set that share to the working folder you want.
Unless I am not following you, the inherit option makes each project a seperate folder within my root working folder....basically I have about 20 different VB6 projects that all need to run from the same directory. I am guessing that I am stuck until you/if you make this an optional rule. Any idea of a timeline and can I be on a beta for it? Also, is it possible for me to rollback to 3.1? Im stuck if not....
Brian
Brian
Sorry, I don't have a timeline on the working folders.
What is the ultimate goal here with getting all the files into one folder? Is it just for a release, or compiling, or something else?
Are all the files in the folders involved? Are labels being used?
Also, has many changes happened to the database since the upgrade, or was this a very recent upgrade?
What is the ultimate goal here with getting all the files into one folder? Is it just for a release, or compiling, or something else?
Are all the files in the folders involved? Are labels being used?
Also, has many changes happened to the database since the upgrade, or was this a very recent upgrade?
basically when debugging, programming, etc, all he projects need to run from the same folder. I've always kept them in seperate projects in Vault to keep them organized, but they all reside in the same working folder. I havent made many changes since the upgrade and wouldnt blink about losing that. Does the upgrade do a backup?
Im not well taught on using Vault so, if there is a better way to do it...I am all ears...just want to avoid having to put them all in one folder inVault if I can.
Im not well taught on using Vault so, if there is a better way to do it...I am all ears...just want to avoid having to put them all in one folder inVault if I can.
If there haven't been changes to the database and you performed a back-up prior to the install, then you can always restore the back-up and reinstall the version of Vault that you had. The upgrade doesn't take care of making a back-up for you.
There are some other options for this such as the sharing the files to another folder and setting that folder's working folder or performing a get out to a different folder where the build will happen or you can use our command line client to write a script to pull the files to a location to build at.
There are some other options for this such as the sharing the files to another folder and setting that folder's working folder or performing a get out to a different folder where the build will happen or you can use our command line client to write a script to pull the files to a location to build at.
Could you tell me a little more about what has to be where and maybe I can think of some easier way to deal with this? Is it only the executables that need to be in the same folder? How many folders and files are we talking about here?My application I inherited relies upon all executables being in the same folder.
basically there are functions in the app that rely on the directory that the app was launched from. So the vbp files need to be in the same folder as the other executables, and if I am working on more then one dll at a time, both vbp and included files ned to be in the same folder. As a temp thing I shared all the projects in Vault to one project fodler and just sorted it by file type, so it isn't too much of a pin to find what I need when I need it, however now for some reason now matter what I open or how I open it, I am not being prompted to login to vault when opening a VB project. I seem to have lost the Vault interface in VB6. I tried reinstalling Vault client, but that did nothing.
I don't know exactly what you mean. Is there no source control listed in the Add-In Manager? It would just say "source control", not Vault.
When you installed Vault, did you select to have it as your default source control?
When you installed Vault, did you select to have it as your default source control?
Last edited by Beth on Tue Dec 19, 2006 4:27 pm, edited 2 times in total.