At work I just started using Subversion with AnkhSVN instead of Visual Source Safe. I managed to integrate it well enough but it doesn't seem the same.
Using VSS the following would happen:
A user check out a file by right clicking and selecting "check out" or by editing it. If another user tried to modify the same file he would get an error. No 2 users could edit the same file at the same time. No fancy merging. No conflicts and no conflict resolutions.
I understand the the philosophy behind Subversion is different but is there any way that this behavior described above could be duplicated with Subversion?
There is an option in AnkhSVN called "Automatically lock files on change..." but even if I activate this option when I edit a file it never gets automatically locked.
Even if this option worked the other users wouldn't see the lock until they commited the file. They wouldn't get an error when they tried to edit it like they would in Visual Source Safe.
So basically: can Visual Source Safe's behavior be duplicated using Subversion and AnkhSVN?
The point of using subversion over source safe is that you don't have exclusive lock and many people can work on the same file.
You are loosing quite a lot of the benefits of SVN if you start using it with exclusive locks on files.
The idea is that you fix conflicts during merges of code.
See this SO question and answers for a bit of a discussion on the issues (Revision control locking: Is the jury still out?).
The Agent SVN is a MS-SCCI plugin (just like VSS) for Subversion so it integrates with Visual Studio just like VSS.
It also has a Lock on check out option and with that feature on it does feel a lot like VSS.
You need to set svn:needs-lock subversion properties on the files that you want to explicitly lock. It's really only recommended for files that cannot be easily merged, like (most) binary files and not on text/code files. Usually text/code files merge great automatically, and when they don't conflicts are usually easy to solve.
AnkhSVN will ask you to take lock the file (same as checkout in VSS) when you attempt to edit it when the svn:needs-lock property is set. If you enable the "Automatically lock files" feature, the lock dialog is suppressed, and you will take a lock on the file without a dialog showing up.
Svnbook explains the differences between a lock-modify-unlock and copy-modify-merge, and the svn:needs-lock behavior is also described
Related
Recently switched jobs and with it switched source control from TFS to SVN, which is new to me.
In TFS there was an option to disable automatic checkout of files when you started typing in them. It's enabled by default and a lot of users like this behaviour, but I prefer to know for certain what's being changed before committing. A personal thing.
VisualSVN auto-checkouts by default. Is there an similar option to turn it off? I can't seem to find out in the settings.
"Automatic checkout" term in SVN and in TFS worlds has different meanings, as far as I see.
In Subversion, checkout relates to svn checkout operation which gets a working copy from a repository. In TFS it looks like the term somehow relates to automatic locking mechanism.
If you want a file to be locked automatically when you start modifying it in Visual Studio (with VisualSVN extension installed), see the KB article "Lock-Modify-Unlock Model with VisualSVN". I also suggest reading the SVNBook chapter "Locking".
Generally speaking, you can set svn:needs-lock property on files. The property instructs client which files must be locked before editing. After applying svn:need-lock to a file the file gets read-only attribute. Before editing the file must be explicitly locked by the user. After committing the lock is released by default.
Short answer: I don;t think you can do this without becoming very unpopular.
I think you should read up on the SVN redbook's description of how SVN works, especially the versioning models
In your environment, everyone wants to be able to modify any file locally and then send their changes to the server, merging changes with colleague's changes if necessary. This approach works well if 2 people are not changing the same files all the time, which is typical of most dev shops.
The old TFS/VSS model of checkout a file to work on it is pretty obsolete today - the more 'optimistic' approach where you assume you have exclusive access is much more productive. (as usual its easier to ask forgiveness if it goes wrong than ask permission every time)
Your main problem is that you cannot mix these models - if your colleagues are using the merge model, then you have to as well. You cannot lock a file and expect them to still be able to change any file anytime.
Now, there are tricks you can use to prevent yourself from modifying files you never meant to - I'm not sure of VisualSVN but TortoiseSVN (awesome tool) can run client hooks - ie you can write a program to run on every checkout, and that program can be as simple as setting every file's read-only flag. Whether this is god enough for you is another matter.
Personally, I would get used to the idea of change whatever you like whenever. If you accidentally edit a file, you can see the change indicator (AnkhSVN turns the file icon orange for changed files), and its easy to 'svn revert' changes you didn't want to make. Also SVN lets you see diffs really easily, especially on commit - double click the files in the commit dialog. The productivity gains from being able to work without the tools getting in your way (as I found with TFS continually pinging at me as I tried to edit a file) are huge. The SVN tools are really good to let you "ask forgiveness" so you don't need to run in the crappy old TFS way now you've upgraded to something better.
The other advantage is that this applies to files that are not in a Visual Studio project, if you've ever had a project file that was edited outside VS (eg a generated WCF client stub) then you will appreciate how SVN works - never again will you do a full commit and find that TFS has conveniently decided that your changed file wasn't changed and so didn't need to be committed!
I just started at a new company which uses VSS and has "Allow Multiple Checkouts" turned off. I can see that it is going to quickly become a problem getting things done here. Getting "Allow Multiple Checkouts" enabled is probably not an option.
Is there a way for me to edit the file anyway and then merge my changes (either using VSS or another tool) when the file becomes available?
Sure, just make the file writeable (hold the shift key down when clicking the get button to get the dialog...)
Then try not to break anything when you merge your changes.
No shop I have ever worked in allows multiple checkouts because the merging process is so dangerous.
Basically, nothing prevents you from editing the files. Usually these filese are marked read-only, but you can surely override that.
But better be very careful, because VSS would allow you to easily overwrite anyone else's changes.
There is an option in VSS Studio to make the files read-only unless you have them checked out. You might consider turning it off (though I wouldn't recommend that).
I believe, there's also an option in Visual Studio to allow editing read-only files. That is, if you try to edit an r/o file, Visual Studio will prompt you to make it writable. This is probably better, since you will not change the file accidentally.
Even better, migrate from VSS to SVN or another modern source control system.
VSS has lots of potential problems with stability, performance and so on.
I am working on a large source base (approx 15K files) decomposed into about 25 projects. I want to keep the source in perforce (and am evaluating perforce to that end) but due to complications in the setup it isn't possible for me to keep the visual studio projects in source control, I know in theory the answer to this is to check the projects in, but that isn't feasible (we would end up with projects for several versions of VS checked in, and additionally several variants of each of these, instead they are generated automatically and this setup works very well).
Is there a way to get VS to checkout files for editing as it goes without adding the project to perforce, to avoid the user having to go to the perforce client and manually check out each file for editing as they go? Alternatively (and even better) is there a way to get VS to recognise that the files in a project are under source control, without having to add the project to source control also?
I know we could also take the tack of having every user check out for editing all files they might potentially want to edit ahead of time, then revert unmodified files before submitting their changes, is there a performance penalty in perforce in taking this approach?
In your case, I'd suggest not using the visual studio integration for Perforce.
You can either add Perforce commands to the Tools Menu, or try Nifty Perforce from Google:
http://code.google.com/p/niftyplugins/
One option is to use Perforce as if you were disconnected from the server and reconcile your changes later, rather than telling Perforce everything you do before you do it. (This is roughly equivalent to the workflow in CVS or Subversion.) You would synchronize your working copy, go off and develop, and then ask Perforce to figure out what you did while it wasn't watching.
Perforce has a nice document describing the process: Working Disconnected From The Perforce Server
One thing the document doesn't mention is the allwrite clientspec attribute, which marks all files in your working directory as writable instead of only the files you have checked out.
For the sake of completeness: There is a new tool for your wish called P4VS. I like it better that P4SCC which never worked for me as I wanted.
I'm using Visual Studio 6.0 and Visual Basic 6.0.
I have them integrated but when I check out a Project and then try to edit a module in that project it's locked and I have to manually right-click on it and do a Check Out to unlock it.
I thought there was a way to have VSS automatically check out the file for editing.
Any suggestions?
I agree with kris here. Now I know that a bunch of folks saying your "software stinks" doesn't really answer your question. But there is a world of difference between a check out style source control and a file locking system like Source safe. The general consensus is that Check out systems are far superior.
With check out, what you do is you check out the project from your repository. All the files are editable. You work on your project as normally. Then before you checkin you do another update. If anybody else in your team did a update the software will automatically merge in the changes into your code. You will have a chance to review the merges and resolve any conflicts. After the update you can then check in your changes which everyone else can retrieve.
The big scary part is the merging part. Back when CVS and subversion where just command line tools it was a little scary as it was a pain to retrieve what happened with the merging. But with today's tools like Tortoise is all visual. In the last couple of years I can't think of any instance where a automatic merge failed. Any conflicts (basically two people edit the same line of code) are display right here for you to resolve.
Subversion
Tortoise SVN
There is an option in SourceSafe under the "Local Files" tab labeled "Use read-only flag for files that are not checked out". By default this option is selected, but if you unselect it, you will be able to edit any file in the project without checking it out.
Once you uncheck the option, you can get the latest version of a project to remove the read-only flag from all the files.
When you check out a file, you will be warned that there is a writable copy of the file in your working folder, at which time you can replace it with the version in the SourceSafe database.
I never figured out a way to do this. It was always a huge pain. Sorry for posting a negative answer, but I figured that you might want to know that you aren't alone in hating this, but that there wasn't an immediate and obvious answer. I'll be following this question along with you in case someone out there does know of a solution...
I don't think it is possible to do this (at least it wasn't when we used VSS eight years ago), but while you are experiencing the pain of a check out styled source control, run - don't walk, to some real, non-locking style source control solution. SVN, CVS, Git, Mecruial, anything that doesn't lock files, and doesn't leave your source in a proprietary file sytem. We switched to CVS eight years ago because we lost all of our source history (the code was checkout out so it was retrievable), due to a VSS glitch. Best thing we ever did, made collaboration ten times easier. Now CVS isn't the best solution (it was the most reasonable solution for windows back then), but anything is better than VSS.
Best solution I found was to check out all the files. Took a bit of poking around to figure out how to do that. Here's how:
How to check out all VB6 Project files from VSS?
when I check out a Project and then
try to edit a module in that project
it's locked and I have to manually
right-click on it and do a Check Out
to unlock it
Like it or not, it works that way by design i.e. you can check out all the files but you have to explicitly choose to do so, rather than being the default option. I guess that's because checking out all modules (class modules, forms, usercontrols, etc) locks out all other users from the entire project, which is normally undesirable in a team collaboration environment.
I have a VS2005 solution which contains a variety of projects (C++ DLLs, C++ static libraries, C# assemblies, C++ windows executables) that are combined in various ways to produce several executables. For some reason, every time I open the solution, VS2005 wants to check out one of the projects for editing. The project is not modified in any way, it's just checked out. If I configure VS2005 to prompt before checking out, I can cancel the auto-checkout during load with no ill effect that I can see. It may or may not be relevant, but the project it keeps checking out is cppunit version 1.12.0 (the static lib version). How can I stop this annoying behavior?
Other potentially relevant (or not) details:
Source control is Team Foundation Server (not Visual SourceSafe)
no .suo or .ncb files are checked in
the .vcproj and .vspscc files are being checked out
When I close the solution or shut down Visual Studio, I'm asked whether I want to save changes to the project. Answering yes results in no changes to the file (Kdiff3 compares my local file to the server version and reports"files are binary equal")
Attempting to check in the "modified" files results in a Visual Studio message saying "No Changes to Check In. All of the changes were either unmodified files or locks. The changes have been undone by the server"
As Charles and Graeme have hinted at, Visual Studio constantly make changes to user option files and such on the backed even if you don't make changes to the project directly.
I'm not sure what information is being stored but I do know that it happens. Common remedies is to not include the *.suo files. I also don't stored anything in the bin or obj folders in sauce control as this can have a similar effect as your talking about (if you build). (Checks out the project upon a build. Thought this does take an action to happen).
Overall it is unavoidable. It is just how VS2005, 2008 work.
Does this answer your question?
Regards,
Frank
There are two reasons I've encountered that cause this behavior.
The first is old source control bindings. If you have a project that used to be managed by another source control tool, it might have leftover bindings in the project file. Open the project file, and change the following settings from something like this:
SccProjectName="$/Team/Platform/Projects/MyProject"
SccAuxPath="http://teamFoundationServer.example.com:8080"
SccLocalPath="."
SccProvider="{88888888-4444-4444-4444-BBBBBBBBBBBB}"
to this:
SccProjectName="SAK"
SccAuxPath="SAK"
SccLocalPath="SAK"
SccProvider="SAK"
Different project types are defined in different ways. The above example is from a .vcproj, C# projects are in XML, VB looks like something else, but the meanings are the same. Simply set all four values to the constant string "SAK" and Visual Studio will automatically handle source control. See Alin Constantin's blog for details.
I haven't yet discovered the root of the other reason, but the project that is giving me trouble is also CppUnit 1.12.0! I'll keep digging and post my findings.
John
Have you put a .suo or .ncb file into source control perhaps?
Have you tried closing VS2005 after it checks out cppunit and then seeing if any changes were made?
I often encountered something like this with Web App solutions where the project file wasn't actually saved until you closed studio down and reopened it.
Just to clarify, I'm assuming that you mean Visual SourceSafe2005 is causing the problem, not Visual Studio. (FYI, Visual SourceSafe is usually abbreviated VSS.)
I've experienced this issue with VSS before. I think the limitation is really fundamental to Visual SourceSafe: it's just not that good of a product and I would move to something else if it's a decision you can influence.
If you can move to something else, I recommend Subversion for a small or medium-sized project. It's free, and does not use the pessimistic locking mechanism that Visual SourceSafe uses by default. There's an excellent Visual Studio add-on called VisualSVN that will give you the same functionality in the IDE (seeing what files have changed, etc.) that you get out of the box with VSS.
If you cannot change source control systems, I believe Visual SourceSafe has a mode called "non-exclusive checkouts" or something like that that uses the optimistic locking that Subversion and other source control systems use. Try setting that option at least for the files that are obviously not being changed and see if that resolves the issue.
I get this a lot when one of the projects in the the solution has source control information with path information that is not the same in source control as on your workstation. When VS opens the project it will automatically attempt to check out the project in question and
To fix it, you're best off having everyone who uses the project remove their local copies and do "get latest version..." to grab what is in your source control database.
you can also check the .sln file and look in the GlobalScxtion(SourceCodeControl) area for each project's information and see if the relative path is not how you have the projects stored on your workstation - though manually changing this file vs. doing a "Get Latest Version..." is much more likely to cause problems for the other developers who use the solution as well.
Your cppunit project is probably automatically creating one or more additional files when the project first loads, and then adding those files to the project. Or else one of the project's properties is being changed or incremented on load.
If you go ahead and check the project in, does it check itself out again next time you load it? Or does checking it in fix the problem for awhile?
Very often this sort of behavior is caused by VS trying to update source control bindings.
Graeme is correct, VS will not save project or solution files until you close VS.
I would let VS check the files out, then close VS, then diff them.