I and another developer are working on the same VS 2008 project using Source Safe. If one of us needs to add a new item, the person who doesn't have the csproj file checked out gets a message that they can't add because csproj and vspscc files are checked out.
Is this the normal behavior of Source Safe? What's the workaround beside asking the person to check in or to use another source control software?
You can turn off exclusive checkout in SourceSafe via the Options dialog, Allow Multiple Checkouts checkbox. This will allow you and your co-worker to both have the .csproj checked out at the same time. However, if you both make changes, you will need to merge those changes when the second person does their check-in -- and SourceSafe has notoriously weak merge tools compared to other version control systems. So although multiple checkout can be a lifesaver, you'll still want to avoid it where possible.
That was 'normal behavior' back when I used VSS in 200-2006 time frame. There might be some options in VSS to turn off "exclusive checkout" which would let both of you check out the file at the same time, and whoever checks it in 2nd has to do a merge.
Related
I work in Visual Studio on C# project.
I edit some files it that project simultaneously. After some work is done i want to divide all changes to "groups" of changes and commit each group changes to separate commit. Its okay when it comes to files - i include one files, exclude others and all is fine.
But problem appears when some changes are in the single common text file. I'd like to split them to different check-ins by TFS itslf, but as far as i know it is not possible.
So tell me please, is there any way to split changes to distinguish them due development process? For example when i start editing common file i press something button or issue a command. Later, when i have to add changes regarding to another check-in to that file, before these changes are really done, i press another button (another command) and since this moment changes are recording as needed to be commited to another check-in.
I hope you understand what i mean. Sorry for my bad English.
If you are going to make a quick change to a file that has work in progress, you should shelve the changes and revert to the source control version (uncheck the "preserve pending changes" box). Then you can make the changes and check in the file. After that, unshelve your changes (your work in progress) from earlier, VS will merge the changes with your checking and you can carry on.
Since it sounds like you have already made the changes and the file contains code you are ready to check in and code you don't, one thing you can do is to shelve the changes now (but do "preserve pending changes"). Then you can delete any code that aren't ready and check in the file. After check in, you can unshelve your changes.
You might want to consider using branches to isolate your long-running changes; although that has its own set of problems.
You could create another workspace on your computer, and use each workspace for a different task. That way, you can work simultaneously on different tasks on the same file without affecting each-other. When you check-in from one workspace, do a "get latest" on the other workspace and merge the changes there before you check-in the other work.
I have a project that I have been using VSS source control from the VS Pending Checkins tab. This has been working until recently. Now when I make a change to the code, I do not get an entry in the Pending Checkins tab.
I saw this article, but did not see a Go Online option either when right-clicking on the solution or under File -> Source Control. Probably because that person was using TFS rather than VSS.
I tried breaking the source control links and creating a new tree, but it still didn't check out automatically when I made changes. I have been using the Check Out For Edit option, and then checking in, but this gets all classes whether I make changes or not. I use source control in VS because the list makes it simple to determine whether I need to check something in or not.
Does anyone have an idea as to why this may have stopped working with this project. It is still working in other projects. I do have "Check out automatically" selected for On Save and On Edit. Allow checked-in items to be edited is not checked, nor are any of the other options under Source Control -> Environment.
Thank you for any suggestions you may have.
UPDATE: I just added a new class to the solution, and that class appears under pending checkins. However, I also made several changes to other classes, and none of them are appearing under checkins.
I too rely on SourceSafe via Visual Studio to automatically check out files. But it usually just works by default although with certain assumptions you need to know that I learned from this post which explains the risky methodology:
If you Get all files without checking them out then the files will be read only as you can see in Windows Explorer properties. Then, when you type your first edit to any file, VS/ VSS first checks for the read-only attribute on that file. If it is read only then the file will be automatically checked out (this is the default option). Then, when you are ready to check-in a set of files, VS will show you all “Pending Check-ins” and you can check them in as a set.
I have relied on this for years as it has been working great for me in our environment until a few weeks ago when many of my source files lost their read only attribute somehow. So without read-only, some of the files were not getting checked out and therefore not getting checked in. And that’s really hard to detect until your hard-drive crashes and you try to build from another machine!
And I found a method here to fix the read only attributes:
check in all files that were edited (used VSS to find out which files where
changed [using differences] even though VS did not checked them out). Then did a Get Latest with
overwrite of local files and made sure the "Keep writable" checkbox was not
checked.
Shamefully, we use TFS at work for a C# project. I wish we could move to svn or git, but we can't change that. All of us working on the project hate the automatic check-out "feature" of TFS, so we checked in our solution and project files as unbound from TFS.
Now, whenever we open the project, we get the following message:
The solution you have opened is under source control but not currently configured for integrated source control in Visual Studio. Would you like to bind this solution to source control now?
Is there a way to disable this message while keeping the solution unbound from the buggy and annoying integrated source control?
The message you reference has nothing to do with TFS, it has to do with integrated source control within Visual Studio. If you really want to get rid of this message, go to Tools->Options->Source Control and set your source control provider to "none."
Then, go and download the Team Foundation Power Tools and enable the shell access, and you'll be able to right click within Windows Explorer and check in from there. If you don't want to do that, you can do your check-ins from the TF.EXE command line.
But seriously, if you don't like the automatic check-out, then just turn that off. You have the option of having TFS automatically check out, prompt you for check out, or do nothing and leave the files in a read-only state until you explicitly check them out.
Another possibility could be to move to a 'git-tfs' combined solution. You would move your team to git, and sync with TFS on a regular basis. This way, only one person has to live with the TFS annoyances.
I have no experience with that, but apparently it has been tried before
If you like the svn/git model better, then I honestly wonder why you would want to turn off automatic checkout? You can configure VS to silently check out files on edit. This comes pretty close to the svn way of working, no?
Also, ensure that the TFS server is configured to allow multiple checkout on all text-based files, and you should be good to go. You can also install your own diff and merge tools (e.g. TortoiseDiff/TortoiseMerge) if you want.
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
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.