Forgive me, but I don't know the technical term to know what to search for.
I am trying to find a way to keep track of changes in my code during the development of my program. something that would allow me to go back to a section of code that I deleted. I am not talking about "undo". But rather a way that would let me keep track or be able to retrieve a section of my code that I deleted but now want it back.
Is there such a way? If there is, then what is this whole system/procedure called? Is there something that integrates with Visual Studio 2010?
you could use
SVN
or
GIT
but for local use, I would prefer SVN. its free and its easy.
For visual studio there are a few SVN client plugins (like VisualSVN). But, I would suggest TortoiseSVN as the client.
To be clear, SVN is the server, TortoiseSVN is the client. (Both are free open source tools)
It's called Revision Control.
The term you are looking for is Source Control. Modern source control's provide all the functionality you described plus much more.
Team Foundation Server seamlessly integrates into VS2010 and is very useful. Read through Source Control for Visual Studio to get up to speed.
I'm not familiar with Visual Studio, but generally there are two approaches to implementing this:
1) Source/Revision control - But the problem is that it is very low-granularity, you usually commit a file when it is ready, but lose any interim changes. There are a lot of solutions compatible with visual studio.
2) A local history that tracks multiple versions between commits. Eclipse has this built in, not sure how to access it in VS.
3) A very granular log of all your development activities so you can examine and revert past changes. Not familiar with a commercial version of this. I once developed something like this for Eclipse.
Please read this thread here at SO: Keeping track of changes I make by copying project folders.
subversion has a lot of mind share these days, but it's very old-school, first-gen tech. Distributed revision control is gaining a lot of momentum and I'd highly recommend that you become familiar with it if you're going to be a code monkey professional. Look up mercurial (also referred to as hg) or bazaar. If nothing else, perforce - a professional, commercial revision control tool - is free for up to two users. It works very well, as long as you keep your branching craziness to a minimum.
Every source control does that, you know ;)
YOu have a legal VIsual Studio 2010? Try Team System.
Related
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.
We are using Tortoise svn as we have some issue we are going to move to VSS. Is Visual source safe comes along with VS2010 or should we buy separately and install. When we called and asked they said to select VSS from Tools->options->Sourcecontrol. If I do so I am getting some error as
As someone already answered on a comment, VSS does not come with VS2010.
In any case, I would strongly recommend against using VSS as your source control. It is several generations old technology as source control systems go.
It has serious drawbacks for the whole development process compared to the modern competition and should be generally avoided.
I have no idea what problems you have with SVN, but I would bet they are more of the organizational sort than technical.
From your comment I can infer that you expected SVN to give you same type of pessimistic locking workflow you had coming from VSS, but with SVN and other more modern tools, you have to change your expectations and workflow to a more natural parallel development.
In SVN you do not need to keep track of who changes what, as everyone can check out and modify every source file in the source tree and in most cases unless the developers change same lines in a same file simultaneously, the changes get merged together without any manual intervention whatsoever.
Instead of acquiring exclusive locks to a source file to modify it, you synchronize your local working copy before commiting it back to the repository and resolve any conflicts locally. This way nobody needs to keep track of who is working on what, just remember to update the working copy and resolve any odd conflicts before a commit.
Visual merge tools hep here tremendously.
Once you've converted, you'll love it and never want to go back.
If SVN does not work for you, there is a commercial tool called Vault by nice guys at SourceGear specifically designed as a replacement to VSS.
In case you feel especially adventurous and liberalized from the VSS, you might also take a look at the Veracity by same guys - a distributed version management tool much like the popular Git and Mercurial.
VSS does NOT come with VS2010 but you may still use it as a form of source control...although this is highly advised against.
Is there a way to disable the "Pending Checkins" processing which Visual Studio 2008 does every time one opens a solution? It's causing problems at our work because the processing of about 4500 files is slow.
Closing the tab didn't seem to help. I also tried the "Perform background status updates" -setting in the Options - Plug-in Settings -window but that was also a no-go.
Any help is greatly appreciated.
Please refer to this link. The possible solutions are listed here http://social.msdn.microsoft.com/Forums/en-US/vssourcecontrol/thread/bf1b12ec-c61f-470a-a9fb-4fbad708f085 (Refer to the third comment in the thread)
A simple option... disable the VS integration with your code repo. I find working with TortoiseSVN (for exampel) outside of the IDE works perfectly well, and causes no IDE issues.
There are obviously other (but similar) tools for different repositories. Since you mention VSS, the Visual SourceSafe Explorer might be an option.
4500 pending checkins seems like a large figure (especially when you bear in mind VSS is only really suitable for small projects)- do you checkout the entire solution? You should reconsider why you need so many files checked out. I've used multiple checkouts in VSS (with some success) to prevent "checkout hog" syndrome- where one person checks out way too much stuff because "they need to make a large change". Better still move to a repository that doesn't require checkout (e.g. Subversion).
It looks like if you don't change your approach you are stuffed.
I'm using VisualSVN with my Visual Studio 2008 and I have to run some sort of commit monitor in the tray area to see if the local copy of project is out of date.
I have two problems with that:
I hate to have it in two places, I want to see that as an icon in my VS,
The commit monitor software keeps an eye on several projects, when I work on project 1 (which VS knows about), I'm not interested in other projects.
I couldn't find any addons for Visual Studio to do that and was wondering if anyone knows about anything good.
Generally, you have 2 options (besides running commitmonitor as you already do):
run update before you start to change something
ignore it all and merge with any updates when you want to commit.
SVN's really designed around the 'wait until you're ready and merge it all together' model, as there's no guarantee that even if you update your working copy immediately before starting to modify it, someone won't commit changes before you've had a chance to commit. So, let the system do the work for you.
The ultimate alternative if you are worried about conflicts is to use the svn:needs-lock property which means you will have to get a lock on any file you modify before modifying it, and you won't be able to get a lock on a file someone else is modifying.
You might like to ask the VisualSVN people if they'd add an option to check the repository when a project is loaded by VS (or run AnkhSVN and implement this feature yourself).
Work has started in AnkhSVN in this direction, we started to implement the 'Synchronize View' that's also used in Eclipse/Subclipse. The things still missing are: Scheduled checking of the repository, and maybe a notification inside VS to tell you that something has changed.
Right now you can manually refresh this view to see local and remote changes (and merges which can be potential conflicts). Patches are welcome to extend this feature :-)
I'm assuming VisualSVN is your "server" (even if running on the same machine).
AnkhSVN is a good Visual Studio Integrated SVN Client.
I just wonder what the best approach is to have multiple users work on a Project in Visual Studio 2005 Professional.
We got a Solution with multiple Class Libraries, but when everyone opens the solution, we keep getting the "X was modified, Reload/Discard?" prompt all the time. Just opening one project is an obvious alternative, but I find it harder to use as you can't just see some of the other classes in other projects that way.
Are there any Guidelines for Team Development with VS2005 Pro?
Edit: Thanks. The current environment is a bit limited in the sense there is only 1 PC with RDP Connection, but that will change in the future. Marking the first answer as Accepted, but they are all good :)
What you need is source control.
You should definitely not open the same files over the network on multiple machines. For one thing, Visual Studio has safeguards in place to prevent you from modifying certain files during a build, but it has none of that that will prevent others from modifying the same files over the network.
By setting up source control, each developer will have a separate copy of the files locally on his or her developer machine, and periodically communicate with the source control system to check in/commit changes. After that, other developers can ask for the latest updates when they're ready to retrieve them.
Use source control to keep a central repository of all your code. Then each user checks out their own copy of the source code and works locally. Then submits only the code that changed.
https://en.wikipedia.org/wiki/Version_control
A number of people have recommended using source control and I totally agree. However you also need do the following.
Exclude your personal options files from the repository (eg your .suo files)
Exclude your App.config files from the repository. - Not entirely but you need to have a Template.App.config. You commit that instead, and only copy your App.config into the Template.App.config when you make structural changes. That was each user has their own individual config for testing.
There are probably some other files worth excluding (obj directories and so forth) but thats all I can think of right now.
Peter
This might sound snide, but if you're opening up the solution from a shared location then you're doing something wrong. If that's the case then you should start using source control (something like Subversion) and have everyone check out a copy of the project to work on.
However if you're already using source control, then it might be a symptom of having the wrong things checked in. I find that you only need the sln, and the vcproj under source control.
Otherwise I don't know...
You should definitely, definitely be working with source control!
This will help stop the collisions that are occurring. Also, if you are making changes to the shared projects this often that it is a problem, then also ensure that all code is tested before getting checked in (otherwise they may bust someone else's build), but make sure they check in often (or time gained from not dealing with prompts will be lost in merging conflicts) :)