Recently we migrated from VSS to SVN. But I don't want VSS removed totally, instead I want everyone can access it read only? Is it possible? How?
In VSS admin you can set each user to be read-only.
Related
I was trying to check in some changes to tfs, then I got a prompt asking me for my credentials. My password seems not to work anymore (I don't know why). Since the tfs is for my own personal use and installed on my local machine, I'd just to start over, i.e. created a new instance of the source control.
First of all, is there a way, I can reset the password? If not, how do I create an new instance of tfs on my machine?
Thanks for helping.
Clean the Cache folder under: C:\Users\username\AppData\Local\Microsoft\Team Foundation\x.0\Cache.
Go to Control Panel--Credential Manager, remove all credentials.
Go to Team Explorer--Manage Connections--Connect to Team Project, click Servers, and remove your TFS, then re-add it.
As usual I extensively searched for a solution before asking here, I'm really stuck.
I'm currently working on a customer TFS server and I have no administration rights whatsoever. Me and a colleague were using the same user account, which I know is a bad practice but again I had no choice here.
Today we found out that the account is expired and the customer is saying that it will not be reactivated. Instead they gave us a new account.
The problem is that in our local workspaces we had some uncommited changes. I'm trying to find a way to reassing the local workspace to a different user but every path I tried leads to a dead end.
One thing I tried was to access the current workspace and set it to "Public" so another user can work on it, but I can't access the current workspace as I am offline and the user is expired.
If I change TFS credentials and try to Get Latest Version or anything else I don't see the old workspace but only the workspace(s) of the new user, which has no "Use" access to my local workspace.
I also read that a manual merge of the changes (using KDiff or Winmerge) is discouraged as TFS doesn't see edits done outside VS so it wouldn't know the files have been modified. I personally noted this behaviour when I tried to change some nodes in .csproj files with Notepad++ and TFS didn't give me the file in the pending changes.
Anyone knows the proper way to work with a new user without losing the local changes?
Thanks.
1)Create a branch for the latest change set from the server
2) Check out the files to your workspace
3) Overwrite the files in worspace
4) Now the branch contains your changes
5) Merge the branch which contains your chnages with the latest.
You have three options:
If you are using TFS 2012+ and VS 2012+ you can create a new workspace as the new user and make it a 'local' workspace rather than a server workspace. Then just drop the changes in a VS will detect them.
If you are using an old version of TFS and/or VS you can use the 'go online' option (2010 only)
If you are using a really old version you may need to checkout the entire workspace before dropping the changes back in.
Update: In order to achieve a merge of the changes you could create a branch from the last/latest changeset that you 'got' from the server. Then just overwrite you files... You now have a branch with just your changes and you can then user the merge tool to stitch it back together.
note: Also note that you should check in code frequently (at least daily) to avoid this issue in the first place.
If one chooses to "prevent other users from checking out and checking in" from Team Foundation Server:
Can anyone reach the code?
Is there any way to work from another user's computer?
How about shelving?
I would interpret that sort of lock as meaning that someone is going to do something so destructive that it is in your interests to not have an edited copy when that happens. If you think it is a mistake, talk to the person who locked the file.
An option, if you really want to do this, is to remove the readonly attribute on the file yourself (in Windows Explorer or through a shell) and edit the file. That is a good way to cause yourself trouble, though, if the file is going to be changed substantially by the person that locked it. Also, you will need to later mark it as checked out in TFS to actually check it in.
I do not think you will be able to shelve the file (unless you follow the option below) since you will not be able to check it out for edit.
One last option is that you could branch the file, work on the branch, and then merge it back in later. Once again, though, that may be difficult if the edits by the person locking the file are going to be extensive.
I'm not sure I understood all of your questions, but I'll give it a chance:
If by reach you mean, get latest version and read, yes they could. But they wouldn't be able to change the code while it's locked unless they circumvent Visual Studio and change the read-only attribute of the with the command-prompt, Windows Explorer etc.
Visual Studio and TFS 2010 introduces the concept of permissions on workspaces. A workspace now can be private (the old behavior), public limited or public. Using a public workspace, on could edit the files in the workspace of another person. See tf workspace /permission for more information.
You can shelve anything that is in your workspace regardless of locks on anybody's workspaces.
Here is a link to the permission values for TFS
http://msdn.microsoft.com/en-us/library/ms252587.aspx
This should answer your questions
I'm using Visual Studio 2k8 with AnkhSVN.
When I start to modify file, it's automatically checkouted. How can I disable it? I don't want to accidentally modify my files.
Your files will not be modified in your Subversion repository until you check them back in. And even when they are checked back in, you can still roll them back to any previous point.
So, no need to worry about doing something accidentally...that's the whole point of version control!
What you call "check-out" just means the file has been marked as modified locally on your machine (without the SVN server knowing anything about it). This is different than say, ClearCase, where the file is actually checked out on the server. So as Michael suggests, you don't really have to worry about it, you can always revert it locally. And if you just use Undo in VisualStudio, the file will again be marked as not modified.
What some of the other answers have hinted at: You don't "checkout" files with SVN. It sounds like you're coming from a ClearCase/SourceSafe mentality. SVN works on a different versioning model. When you "checkout" a working copy, you're pulling down the latest version of the files from the repository. You are free to modify any of them. Once you are done with your edits, you push, "commit" them back to the server.
I could ramble on and on, but instead of botching it, I'll just point you to the de-facto-standard SVN Manual - here's the first chapter which explains the versioning model that SVN uses.
Open the AnkhSVN Conviguration dialog (Tools->AnkhSVN->Configuration…) and set DisableSolutionReload to True.
There is also an option to do the opposite—to prevent it from automatically adding new files to SVN—that you can disable (setting AutoAddNewFiles to False).
We had an employee leave the company, and they left some files checked out in our VSS database. What is the best way to impersonate that user, so I can release those files?
Within ssadmin you can reset their VSS password (so that you know what their VSS password is, so that you can then log in as them using their password).
You could try logging in as an admin and undoing their checkout. You'd lose any work they did locally but if you only care about releasing the file lock it doesn't matter.
The admin can undo the checkout.