I want to undo the old project files that I got from my colleague to understand what was created first. Is it possible? Is there any tool for achieving this?
Unfortunately it's not possible. That would only be possible if you colleague had been using a version control system (like Subversion, Mercurial, Git, TFS etc).
Related
I hope this questions isn't too obvious or vague but I am problems searching for an answer as I'm not sure of terminology.
I am using TortoiseSVN with Unfuddle and Visual Studio 2010.
Previously I used Sourcegear's Fortress which worked really well for me but my new company uses SVN.
The problem I am currently having is:
If I edit a file in visual studio, then commit (Check in) the changes back to SVN and then
My colleague then goes to edit the same file (checks it out) from his visual studio it doesn't automatically update to the new version that I just checked in, so when he then goes to check in the file after he's changed it it throws a conflict error.
So my question is:
Is there a setting that will automatically make it update to the latest version when you check out a file? Or am I using it wrong?
Thanks for any help.
Bex
You don't "check out" files, you should update before editing. Subversion uses a different versioning model than what you're used to.
Also make sure to use a good conflict editor when conflicts do occur. Personally I use DiffMerge configured as both diff and merge tool in AnkhSVN.
I have a visual studio 2010 project under mercurial. I use mercurial either via command line or TortoiseHG. I want to work on a new feature, so I clone the repo. But now I am confused, am I supposed to import an entire new project into VS2010 just to work on this feature? I tried importing the VS Solution that was cloned, but got lots of build errors from dependencies cannot be found errors, which I assume is because I am trying to load this cloned Solution just like the original Solution and some paths are wrong (no idea where though).
How are you supposed to use mercurial and VS2010?
Cloning produces an exact copy of the original repository.
The clone should work exactly the same way as the original repository, so you open your cloned solution exactly the same way as the original one.
If you get build errors in the cloned solution but not in the original one, there are probably some dependencies (=3rd party assemblies that your application needs to work properly) which exist in the original solution, but weren't committed to the repository.
So, when you clone the repository, the referenced files are missing in the clone...so the clone won't work.
Source control works the best way if you check in the complete solution, including all dependencies:
Make a "Libs" folder somewhere in your solution, put all your dependencies inside, reference those files from your solution and commit the whole "Libs" folder to the repository.
If you do it this way, you can clone the repository from a different machine and open the solution, without worrying about any dependencies...it just works.
It sounds like your root problem is that you're adding references using full paths rather than relative paths. You'll need to rectify that before branching is going to be easy for you. I usually make a "References" folder that is on the same folder level as the .sln file, but one level up from the individual projects, then branch the whole thing.
Example Folder Structure
MySolution
MySolution.sln
References
MyProject1
MyProject2
As for VS integration, I use TortoiseHG combined with VisualHG, it works great.
There is also Mercurial Toolbar
Other tools
This may or may not be related, but I've had to load hotfix KB2286556 in order to get rid of the "Unable to update project dependencies" error from VS2010 when building a fresh checkout of our code. It seems this only happens to setup and deployment projects when compilation is invoked from the command line (such as in our build system), but when it happens it's a very frustrating issue to find the solution for.
Also, VisualHg is a good way to track and invoke versioning from within Visual Studio.
While VisualHG still proves to be a wonderful tool after so many years, I would also suggest HgSccPackage as a very viable alternative for all Visual Studio versions (up to VS2015).
PROS: Stand-alone package (TortoiseHg is not required).
CONS: Doesn't have all the handy features of TortoiseHg such as Git support (which I find incredibly handy to handle GitHub-hosted projects) and Mercurial Keyring.
Both of them are freeware and can be installed through the Visual Studio GUI (Tools > Extensions and Updates...).
For a more extensive comparison between them you can also read this post on my blog.
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.
We have a large solution with many projects. Some of the projects were outsourced, and the vendor used TFS. When they commited into our SVN repo, some of the bindings are still hanging around.
When I open the sln, VS2008 says "The source control provider associated with the solution cannot be found, do you want to remove them". I hit yes, save and exit, and then next time it does it all again :)
So - anyone know how I cam get rid of any TFS bindings from the sln once and for all? Do I need to manually search the csproj files for any "scc" references and remove?
Thanks!
Some PDA deployment projects(.vddproj) had some bindings hanging around.
Just removed them manually :)
The way to remove the bindings is to search the csproj files and remove it. There is a similar question on this topic already: See: How to remove TFS source control bindings for a solution from the command line
Here's a PowerShell script to remove the source control binding info. It was ported from some C# and only tested on VS 2010 solutions. The original code was written for VS 2005 and 2008 so you could probably add the relevant stuff back in.
Here you can find a tool (including source code) to remove both SCC footprint from the solution and project files and the .vssscc and .vspscc files. In addition, it removes the output and other configurable directories.
Hth
Stefan
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.