Vault 1.2.3
Background: 99% of what we do with Vault is done via the VS.NET 2003 IDE, with multiple checkouts enabled. We're fairly simple users of source control, with not much branching/sharing/merging/etc. We have some projects under development that are going to hit a release milestone early next week and a few different people are working on those.
Independent of that, I've got a more "R&D" oriented task in front of me that involves a few of those projects. This task doesn't require any source control and is more of a "let's see if this can be done" type of thing.
Much of what needs to be done for this task is new development, but there will also be some breaking changes made to existing source. I obviously don't want to be working on the same code-base as the release milestone efforts.
My thinking is that it would be easiest to have just a local "temp" copy of the source so that I can tackle the task I've got in a fairly isolated fashion. When I do a Get Latest on those projects, obviously they're going to be source-controlled when VS.NET opens them up, so that doesn't work. I was thinking that just getting a copy of a shadow folder would be the way to go, but then 1.2.3 doesn't have shadow folders.
To make it even trickier, I may need to occasionally get into the actual pending-release stuff a few times... so I will still have the source controller release stuff in my standard "working folders".
What would be the easiest/safest/cleanest way to get a writeable "temp" copy that isn't source controlled? If I get-latest to a new place, open the projects, and then "remove from source control", will that have an effect on the projects in the repository, or just that local copy my machine? What if I Get Latest on the projects, point to a different Working Folder, and make things writeable?
Or am I approaching this all wrong?
Thanks,
JD
Get Latest, but separate from source control?
Moderator: SourceGear
There are a few options I can think of:
1. Go to change source control and disconnect (equivalent of work disconnected from source control). Your project will still be under source control, and will ask you to check out files in disconnected mode, but will not actually check them out from Vault. This is a bit dangerous, because if you ever connect again, it will automatically check out files you have changed in the place where everyone else is working, which you definitely don't want.
2. Delete all the mssccprj.scc files underneath your solution and proj folders. This is crude, but has the effect of removing your solution from source control. It will complain everytime you open your solution, but it won't ever checkout files, which is good. You probably want to do a Get to a separate working folder, and do your development from there, so if you need to make changes to the code everyone else is working on, you'd still be able to.
3. Branch your project to a new location within Vault, and continue to use source control in that branch. (You'd need to do a Get to a different working folder for your own branch). You will have created your own sandbox within vault, and any changes you make can be checked in without affecting anyone else. This has the advantage of making it easier to merge specific changes from the trunk that everyone else is using into your code (using the merge branches command).
1. Go to change source control and disconnect (equivalent of work disconnected from source control). Your project will still be under source control, and will ask you to check out files in disconnected mode, but will not actually check them out from Vault. This is a bit dangerous, because if you ever connect again, it will automatically check out files you have changed in the place where everyone else is working, which you definitely don't want.
2. Delete all the mssccprj.scc files underneath your solution and proj folders. This is crude, but has the effect of removing your solution from source control. It will complain everytime you open your solution, but it won't ever checkout files, which is good. You probably want to do a Get to a separate working folder, and do your development from there, so if you need to make changes to the code everyone else is working on, you'd still be able to.
3. Branch your project to a new location within Vault, and continue to use source control in that branch. (You'd need to do a Get to a different working folder for your own branch). You will have created your own sandbox within vault, and any changes you make can be checked in without affecting anyone else. This has the advantage of making it easier to merge specific changes from the trunk that everyone else is using into your code (using the merge branches command).