Feature to block working folder changes

Dino · Post by **Dino** » Sat Jul 29, 2006 11:00 pm

Is there any way you could add a feature to allow me to block VS.Net from ever making any changes whatsoever to my working folders? I seem to spent half my life having to re-set Vault back to the correct folders, whilst VS.Net spends half the time making a giant mess of everything.

Honestly - I do know what my working folders are and I NEVER want VS.Net to change them on my behalf - is there anything you can do regarding this?

Cheers,
Dino

Post by **jclausius** » Sun Jul 30, 2006 8:23 pm

Dino:

If you are using VS.Net / Vault integration, I would strongly recommend changing working folders. VS.Net is in complete control when binding / opening a project from Source Control.

Trying to override VS.Net is like trying to lasso a rain cloud. You won't accomplish anything, and you may also be struck by lightning.

Dino · Post by **Dino** » Sun Jul 30, 2006 9:34 pm

Trust me - no it's not. VS.Net sometimes knows what its doing, other times just leaves me shaking my head.

I had a solution with about 18 projects in it - I made the mistake of adding another project where the physical path didn't match the root of the solution or something, so VS.Net butchered all my paths, and basically made every single file "missing" according to Vault because it moved the root folder up two levels, and everything else was set to inherited. Trust me - VS.Net IS NOT always right, and I get pissed off at having to go back and correct the mess afterwards every time this occurs.

Is there any way this can be implemented, or do I just have to fix it manually every time VS.Net decides to "help me out"?

Dino · Post by **Dino** » Sun Jul 30, 2006 10:17 pm

This is the path to C:\inetpub\wwwroot according to VS.Net:

C:\Documents and Settings\deanc\My Documents\Visual Studio 2005\Projects\Xception\AddIn\Interfaces\Visual Studio Webs

Yep - it decided that my websites are now located in a folder under one of my projects somewhere else completely.

I DO NOT want VS.Net having this control over my paths in Vault - we can argue all day, but I simply do not need the waste of time and aggravation of VS.Net doing this to me all the time.

Post by **jclausius** » Mon Jul 31, 2006 7:27 am

The only way to correct this behavior is to correct it within VS.Net. All the Vault IDE client adds is the "how". The content or the "what" for Source Control operations is solely controlled by Visual Studio.

You may want to check out the Microsoft VS.Net Feedback center - http://connect.microsoft.com/site/siteh ... SiteID=210

It could be an RFE has been logged for something like this. At the very least, you can submit a request for the change.

GregM · Post by **GregM** » Mon Jul 31, 2006 8:02 am

Dino, we don't use Visual Studio integration for exactly this reason. Visual Studio 2003 has its own ideas on where source files need to go relative to the solution file, and $deity help you if your tree doesn't match that.

If you try to override what VS wants, it's just going to cause more problems.

Dino · Post by **Dino** » Mon Jul 31, 2006 3:17 pm

I might think about what to submit to MS on this one.

Greg, it isn't usually so bad, but unless Vault is basically a copy of my hard drive, then things won't map to what VS.Net wants 99% of the time.

This recent issue was 1 solution where every project was under one folder - so no problems at all. I wanted to modify a library that was located outside this root, but made the mistake of adding it to the solution. Based on that, VS.Net took it upon itself to re-map my entire source control to folders to something that were all wrong. No question of whether it could completely overwrite my source control root or anything - it just did. Why couldn't it just ignore that project (or give me the option to ignore it for now) rather than butcher everything?

I'll just have to remember to never do that again, and always open libraries in another copy of VS.Net so that this doesn't happen in the future. But it even happened the other day where I opened a project that was in a sub-folder of another project in the solution - so it's not just when outside the root, it's anything that doesn't match exactly and it throws a wobbly.

ian_sg · Post by **ian_sg** » Mon Jul 31, 2006 3:35 pm

We've not yet announced a date but the next major release of Vault will include a ground-up rewrite of the IDE-integrated client. The new version is not tethered to the MSSCCI API, which is the source of lots of grief. Significantly better project/file location flexibility is one of the improvements you can expect.

Dino · Post by **Dino** » Mon Jul 31, 2006 4:00 pm

Ian - not going to hold you to it, but can you give us a ballpark idea of timeline? 3 months? 6 months? 1 year?

ian_sg · Post by **ian_sg** » Tue Aug 01, 2006 7:40 am

Dino, it's too soon to say. We haven't finalized the feature-set, so any wild guess I might give would inevitably be inaccurate. Sorry!

GregM · Post by **GregM** » Tue Aug 01, 2006 8:25 am

Dino, it's not that Vault doesn't match your hard drive, it's that your hard drive doesn't match the Visual Studio project layout rules. Vault isn't involved in this at all. It happens with other MSSCCI providers as well, and I think even VSS, though I'm not 100% sure on that.

I'd heard here before that the new API available in VS2005 would make this all work better, I'm happy to hear that things are going well.

SourceGear Support

Feature to block working folder changes

Feature to block working folder changes

Look at what the all seeing all dancing VS.Net did...