Actually I have faced this issue many time during working with SVN. Most of the time I am working with VSS for source control but since last couple of months working with SVN.
We are using tortoise and AnkhSVN with VS 2010.
In our team there are 5-6 people and some of them are working on same file at a time. Now when somebody commit , we have seen that some other developer changes get vanished and Sometime we get some line with version number. This thing get consume lots of time and we have to resolve conflict and all.
Please provide information so we can avoid such issues.
If two developers are working on the same file and make changes to the same are of code, then you have to manually resolve this conflict. There is no way to avoid it, no matter which version control you use.
The version control cannot know what the correct code is, so it requires a human intervention.
There is no way around this, other than preventing the users from working on the same code. this is done in svn by locking the file.
Each developer must svn update before svn commit. Between the update and commit, the developer must do a full, clean build and run all tests to make sure their code still works after merging in all other developer's changes into their copy.
You can set svn:needs-lock on files or folders that need to be locked before making changes, they'll be forced to check for locks. When you will try to edit a file, you will be required to lock it first. And when it is already locked by someone else, they you get an error message, preventing you from making any changes. This can be done in Tortoise SVN in Properties -> Advanced
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 pressed Alt-E which I mistakenly thought was Merge Changes In Merge Tool, however, that was actually Keep Local Version. Is there a way to go back? Is there a way to find out what was merged, as in what file? Ugh! :(
I have completely stopped working in case I erase something of importance.
I'm using MSVS 2013 Professional.
Here's another possible approach.
If you know what version of the code you started with before you started making your current batch of changes, you can grab a copy of your local workspace files. Then Undo all your Pending Changes. Then delete all the files in your local workspace (in Windows explorer). Then do a Get Specific Version to get back the old version of the files from where you started, then copy-paste in your updated files from your backup copy. Then do a Get Latest. This should retrigger the Merge process.
I don't know a great answer to this problem, but I do know one thing you can do (I hope you don't have a massive amount of pending changes, or this will get tedious).
The problem is that TFS thinks you have now merged the server changes (other devs changes) into your workspace, even though you told it to basically toss them. If you try to check-in now it will blow away other developers changes in TFS.
What you can do is go through each file in your pending changes window, and do a Compare With Latest Version. This will show you the differences between your local file, and the file in TFS. You will notice two types of differences:
the changes you made which you can just skip past.
Changes that other devs made and are on the server, these differences will show up as though you have deleted/undone that code locally
For the changes that other devs made, you will have to manually reapply them in your local workspace before you check-in.
I made some changes to my website, then had to reformat my server, and over two weeks I tried to undo what I did (it was a stupid forum thingy). Obviously I missed something, becuase now I have the dreaded Build Failed With No Error problem.
This is my home server, so no I am not running source control.
After staring at it for a few days, I decided to try somehting. Today I allowed VS to run the last successful build, and it still works.
QUESTION: How can I go back to the last successful build? I don't care about any changes made since it worked. That's really all I need.
THANKS
Have you checked to see if you have Previous Versions available?
It sounds like you won't likely be able to recover the source files / project config, though you could certainly attempt to recover the "source" by using tools like ILSpy or .NET Reflector. You can use them to examine the output assemblies, and reconstruct your code if necessary.
As a lesson learned, both Mercurial and Git work wonderfully for versioning home projects - I'd give a slight nod to Mercurial in your case as it works just a tad bit easier on the Windows platform.
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'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.