Is there any way to know user creation and modification date using Visual Source Safe 2005 administration? If not, then where can we get this information in server?
No, Sourcesafe does not store this information anywhere.
if you lucky you can determine create date by looking at some "ini" file. I don't remember if each user gets its own "ini" file or not.
Related
In order to organize some T4-generated files within my solution, and per this excellent answer, I have a .reg file that I use to add a key and three values under the following Visual Studio registry key (currently formulated for VS 2015):
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0_Config\Projects\{FAE04EC0-301F-11d3-BF4B-00C04F79EFBC}\RelatedFiles\
Periodically and intermittently, I find that this key has been overwritten and I must run my .reg file again to restore my custom Visual Studio behavior. I have seen this happen every few months or so, for many years, across several versions of Windows and VS, on many machines, and three different domains (on one of which I am sole admin). There's no obvious (to me) temporal association between the overwrites and either Group Policy or Visual Studio Updates, so my best guess is that either Visual Studio is periodically performing some sort of self-"repair", or else certain Windows Updates are overwriting these keys for some reason.
What mechanism is likely causing this (or how could I go about detecting it myself)?
More importantly, what method would be the best practice to either prevent the overwrites or automatically "repair" them when they do disappear? I know I could probably use group policy (where I am a domain admin) to force the registry entries, but I don't have GPO admin rights at every site where I work, and I'd prefer an option that was less ServerFault-y and more StackOverflow-y, particularly because I haven't yet identified the root cause.
You can think of the 14.0_Config key as a volatile cache of VS’s
configuration data for a particular user. It is simply the combination
of HKLM\Software\Microsoft\VisualStudio\14.0 and any pkgdef files
coming from VS extensions.
Source: All Your RegKeys Are Belong To Us
So, in addition to 14.0_Config you can try to add your registry data to the 14.0 key.
I'm working in VS 2010 and am connected to a Team Foundation Server.
In order to edit source files I have to check them out from the server. After I'm done with editing, I have to check them back in (to make changes visible to everyone else) or discard changes.
I am currently in the process of getting acquainted with the architecture and systems, so I'd like to add a lot of personal comments while I play around with everything.
However I'd prefer to not make these comments visible to everyone else. (And I dont want to delete them everytime I commit changes via check-in)
Is there a VS function I did not yet discover or a plugin that allows me to enter comments that dont get commited to the TFS? Maybe something like virtual post-its, just something that lets me attach stupid reminders on certain blocks of code?
(yes I know, proper documentation would make this obsolete but the system is as it is and its huge and I'm not the one to document this all, just want to get used to the code)
VS2010/TFS2010 no built in functionality that I know of, for TFS2012 you could possibly use code reviews.
Maybe the Visual studio extension StickyNotes is what you want.
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 recently realized that my project's .Publish.xml file is being committed to source control. While it seems like the FTP password in the file is encrypted, how safe is it to be storing? Can it be reverse engineered by 3rd parties?
Our own experiences of including the publish.xml file in source control are the password is not stored in clear text but another user can make use of the file to publish to the ftp account, so presumably whatever key is used to encrypt/encode the password is availible somewhere.
The other thing that we noticed was that if you try and publish the project without having the publish.xml file checked out it causes all sorts of problems, even to the extent of causing visual studio to hang, although we haven't conducted much further research into this yet.
Okay. Forgive me, but I'm going to vent a little here. Visual Studio doesn't recognize my TNSnames for oracle so I can't connect to my database. I believe the problem is that I have multiple homes on my machine, one for me (In C:/app/{UserName}/product/11.1.0) and one general one which was already installed on my machine (In C:/oracle/product/11.1.0) and I don't have access to. I don't know why they can't just giv eme rights to my machine (Its not like I would abuse that power, but rather user it to cut hinderences like not being able to edit your freaking TNSNames file).
Anyway. I need to know if there is a way to change my oracle home for visual studio. I edited my PATH variable in the terminal to point first to MY oracle home (C:/app/...) but that didn't work. So is there another way to change the oracle home for visual studio so I can connect to my database. (Maybe in the .vssettings file???)
Thanks for your support. You guys here at stackoverflow are a great community and I am extremely appreciative of your assistance.
-Matt
You don't need to change your Oracle HOME directory. Just make sure there's a tnsnames.ora file in the current HOME directory (the one pointed to by the system PATH) with the propery connection settings. Here's a blog post that walks through the entire process of connecting to Oracle in Visual Studio.
If you have the ability to set a user environment variable, then try setting the variable TNS_ADMIN to a directory where you can create files. Just edit a copy of the current tnsnames.ora so that it contains the entry you need, and place it in the directory pointed at by TNS_ADMIN.