In my company, we use SourceSafe and Visual studio. Starting up a minor project, I am eager to try a more modern source control, I am aiming at Subversion. But I need to work with the previous projects in SourceSafe, at least for now.
Q: Will it work well to use both SourceSafe and Subversion in the visual studio IDE? Using what? And are there things in Subversion I may feel painful if I am used to SourceSafe?
Regarding your first question, I don't know of anything that would stop the two working side by side. You can try Ankh for a free SVN VS add-in, or VisualSVN is a commercial option.
Regarding your second question, SVN has a different model than SourceSafe. SourceSafe requires checkout (pessimistic) whereas SVN you just change your files and commit when ready (optimistic). Any conflicts will need to be merged. Other things differ as well, and you should definitely read basic SVN documentation before you start using it. TortoiseSVN provides both excellent Windows shell integration and good doco too.
PS. Once you try SVN in earnest, you will never look back to SourceSafe.
There shouldn't be a problem using Visual Source Safe and Subversion side by side. Visual Source Safe keys off .scc files within the folders. I also believe the source control is stored in the project files. In any event, Visual Studio automagically handles Visual Source Safe integration.
Subversion (TortiseSVN really) stores all it's metadata in .svn folders. When you install Ankh or VisualSVN, these programs target the .svn folders. If you load a project that has .svn folder anywhere in it's folder structure, Ankh or VisualSVN will kick in.
I agree with other posts, once you turn to Subversion you won't want to go back. It takes a little getting use to. Spend sometime, if don't know already, learning merging and branching. It will serve you will moving forward.
After you get subversion up and going, you might want to look into continuous integration. Cruise Control.Net would be a good tool to start.
Best of luck!
Using SVN technically, won't be an issue - especially with Tortoise +VisualSVN (latter not free but cheap).
The headspace change in going from the usual VSS way of working - pessimistic locking - to the SVN/rest of the world style - optimistic locking will be the harder hurdle.
To explain a little less concisely - if you are used to locking a file when you 'check it out' so noone else can change it, or at least everybody else knowing you are working on it before they try to make any modifications it is quite a leap to go over to not knowing until you try to commit - at which point you have to do merges.
Merging is the tricky bit sometimes, purely conceptually, but especially merges for Winforms with the designer auto-code and the resx files...
Think very carefully about your branching strategy. Best to start just working directly off of trunk to get used to the software before deciding to go for merging. You will find a lot of things quite repetitive and manual compared to VSS - we have a coupla guys here who admin the SVN servers and thay have been invaluable in writing scripts and add-ons for Tortoise to take some of the pain away...
In Visual Studio Tools | Options you can select the source control provider from in there. We used to swap between VSS and another provider some years back and all we had to do was change this when we loaded to project.
If you're using SVN, I would highly recommend looking at VisualSVN for integration in Visual Studio. (Although read comments below...)
I've used TortoiseSVN and SourceSafe in parallel with VC6/VB6 projects in order to keep a parallel log of changes with Subversion (for various reasons, but mainly for keeping proper track of revisions) until we were able/prepared to switch fully to Subversion. I had no problems, I only had to keep an eye for new files coming from the SourceSafe repository.
Working with Visual Studio .NET is a different ballgame if you install AkhSVN, which I did. I worked with it for a few months and ran into problems when AnkhSVN automatically kicked-in when opening SourceSafe-controlled projects. Just avoid mixed SVN/SourceSafe projects with VS.NET, or don't install AnkhSVN.
Related
I have a VS 2015 solution which is under version control with AnkhSVN.
The solution name and one of the projects should be renamed, including the directories.
What is the best way to do this, w/o causing issues with version
control AnkhSVN?
Any good tools available to accomplish this?
I am not very familiar with AnkhSVN, so I can not give a step-by-step guidance. However, you should be able to rename the solution and projects (on disk or in solution config) without issues when you use a Visual Studio plug-in such as AnkhSVN or VisualSVN.
However, you should follow a best practice that will help you prevent tree conflicts after the rename operation: do not perform the refactoring in branches. Perform rename operations and refactoring in trunk (mainline or master).
I have a Visual Studio project that I want to work on in two computers.
I'm looking for how to sync the project between the computers.
I have a few options, and I'm open to other suggestions:
Dropbox
OneDrive, which is integrated nicely in Windows 10.
Github, although I'm not sure if it is used for this purpose, and don't want my code to be public.
What has worked for you?
Thanks!
If you use Visual Studio, then Visual Studio Team Services is good for you.
For source control you can use TFVC or Git and it's free (for team up to 5 people) and repositories are private.
GitHub is a nice choice, not only to share between machines, but mainly as version control.
Also, if your version of Visual Studio supports it, you could use TFS - the versioning integrated to it.
OneDrive or Dropbox doesn't have version control - once your project grows, you will notice it is really needed.
For source control I would prefer tortoise svn (over git and bitbucket) - because it's easier to use.
For data replication / sync - google drive. Its similar to microsoft one drive, but bit faster.
Oh common - downvoters ! :-) I know you're absolutely love git, but unfortunately it's too over abstract, lacks of proper error handling, to difficult to use.
We can skype if you think otherwise, and I can prove it to you.
I'm trying to use visual studio 2010. But it seems that the .sln file that is created through it isn't supported by previous versions. Is it possible to save the projects in a way that it could be readable by previous versions of visual studio (2008).
The accepted answer is incorrect when it comes to projects. It's correct for solution files, but they're not actually as important as the project files (as they don't change as often, in my experience, and there are fewer of them).
For example, you might want to look at Noda Time. We have two solution files (NodaTime VS2008.sln and NodaTime VS2010.sln) which load the same project files. This provides a pretty practical solution to having developers working with different versions of Visual Studio.
Manually change the first part of the project file to look like this:
<Project ToolsVersion="4.0" DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
(Basically just change ToolsVersion to 4.0.)
You can also just let VS2010 convert the projects automatically and compare them afterwards if you want - see whether it's done anything else that you don't want.
At that point, when you build in VS2008 you'll get output such as this:
Project file contains ToolsVersion="4.0", which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion="3.5".
... but it will still work, in my experience. There may be some oddities if you use a lot of designers etc, but generally it seems to work pretty well.
A late answer, but for others in this boat, here's an option if you don't mind conquering a learning curve. Download a copy of TortoiseHg and install it. This is a version control system. (There are other version control systems such as git which can also do this, but they must support patch queues, and TeamViewer does not; however, this isolated usage does not conflict with TeamViewer for source management). Mercurial includes an extension called MQ, and you should enable it. Modify the setup to make Patch Queue Patches secret. ([mq]secret=true, or under settings, Commit, set Secret MQ Patches to True. If you start using Mercurial for change management and do not make patches secret you will suffer great pain as unavoidable accidents occur as the patches are committed to the repository and must be painfully, manually removed from each users copy, only to creep back in via the one user that was on vacation that day.)
Next, create a repository in the solution folder. Look online for an .hgignore file so you don't grab a bunch of crap, but if this is your only goal, you can ignore everything but the *.sln and *.*proj files. Place all of the files in there under the oldest version of Visual Studio you use. Next, open the solution file and allow Visual Studio to perform an automatic upgrade. Then open the TortoisHg workbench and create a new patch that contains all of these changes.
From here on out, you can make whatever changes you like to the source, and place them in another patch. When you're ready to share, open up the workbench, pop off all of the patches, and drag the upgrade patch to the top, and pop all the patches back on except for the upgrade patch. Finish (Repository->change history->finish patch) all of the patches (except for the upgrade patch). Your changes are now incorporated into a version of the solution that is based on the oldest version of visual studio that you have in use.
When you obtain updates from other users, pop your upgrade patch off, apply the changes via a changeset or shared patch, then pop your upgrade patch back on last. Repeat as necessary.
This does not capture modifications to the projects or solution file, since you will pop those back off when you remove the upgrade patch, but 99.9% of all source code is completely backwards compatible. So other than adding new/existing items to a project or adding new projects to a solution, this should cover the majority of your work. For changes to projects, perform those on the oldest supported version of visual studio, delete your upgrade patches, and recreate a new upgrade patch.
Our dev team is small (3 developers) and windows based.
I'm looking for a source control that can do the following:
Check out files for editing and warn others that file is used
Check in files and merge if they have changed
Split baselines for release versions and merge baselines if needed
Visual Studio integration
Can work over WAN
Thanks.
SW
Team Foundation Server fits all of those.
SVN would be great, as long as you use locking (normally the server has no idea what clients are doing by default)
Perforce might be a nice one to look at which does this more by default.
Both have VS integration, SVN especially.
SVN, provided that you explicitly lock the files. This is not by default, but you can easily lock the file via SVN commands or via TortoiseSVN.
VisualSVN provides the Visual Studio integration.
If you want good Visual Studio Integration, then check out Microsoft Team System. You didn't specify if you wanted free or commercial or how critical Visual Studio intergration was.
git will do almost all of it. Not sure about integrating it with Visual Studio though. there might be a plugin for that.
Reasons:
No central server needed. If you want one, you can have one, but it's not necessary
You can push/pull changes to the others at will.
Each of you can have your own local branches, and push only the ones you need to
each other. Branching/merging is easy enough to do branch-per-task. Then push just that task to a co-worker if needed.
Unlike SVN, only one directory is needed for git, in the top level of the directory structure.
git stash rocks for when you have changes in your current branch, and need to switch to another for a while. This is one of those things you don't miss until you don't have.
Merges are awesome.
I'm looking to move to distributed source control since I use multiple computers and often work offline. What if any distributed source control systems integrate with visual studio and how good is the integration?
Have you considered using Git? You can host open source projects on github for free.
For integration please refer to Using Git with Visual Studio which indicates it is possible.
I'm not sure about integration with VS but I have used the excellent Tortoise Windows Explorer plugins. We use Tortoise-CVS and SVN all the time and they are fast and reliable.
They do a Tortoise-Hg plugin for Mercurial as well.
It may sound funny, but I rarely use my VS integration even though I have one.
Tortoises and command line work great, and Bzr and Hg have workable tortoises.
AnkhSVN does the job nicely for me and my team.
Jared,
If you need distributed and VStudio integration, then you're talking about Plastic SCM
The whole GUI is integrated with VStudio 2005 and higher, and SCC integration is available starting with VStudio 6.
It directly supports renaming and moving files from VStudio too.
Plastic SCM is free for students, for open source projects and most likely you can get some free licenses for personal projects too.
There is VisualHG too, with TortoiseHG it is a Visual Studio Plaugin.
I use subversion and tortoisesvn. For integration with VS, I use VisualSVN which does cost money but it pretty cheap and works flawlessly. There are free subversion source control provider packages for Visual Studio and I tried a few but VisualSVN worked so much better so I went with it.
I like using KilnHG (which is an online wrapper around Mercurial) - it's free for small numbers of developers from what I can recall.