I'm using Visual Studio 2k8 with AnkhSVN.
When I start to modify file, it's automatically checkouted. How can I disable it? I don't want to accidentally modify my files.
Your files will not be modified in your Subversion repository until you check them back in. And even when they are checked back in, you can still roll them back to any previous point.
So, no need to worry about doing something accidentally...that's the whole point of version control!
What you call "check-out" just means the file has been marked as modified locally on your machine (without the SVN server knowing anything about it). This is different than say, ClearCase, where the file is actually checked out on the server. So as Michael suggests, you don't really have to worry about it, you can always revert it locally. And if you just use Undo in VisualStudio, the file will again be marked as not modified.
What some of the other answers have hinted at: You don't "checkout" files with SVN. It sounds like you're coming from a ClearCase/SourceSafe mentality. SVN works on a different versioning model. When you "checkout" a working copy, you're pulling down the latest version of the files from the repository. You are free to modify any of them. Once you are done with your edits, you push, "commit" them back to the server.
I could ramble on and on, but instead of botching it, I'll just point you to the de-facto-standard SVN Manual - here's the first chapter which explains the versioning model that SVN uses.
Open the AnkhSVN Conviguration dialog (Tools->AnkhSVN->Configuration…) and set DisableSolutionReload to True.
There is also an option to do the opposite—to prevent it from automatically adding new files to SVN—that you can disable (setting AutoAddNewFiles to False).
Related
Thinking about using Team Foundation Server with VS2012 or VS2013. Does TFS track every single local change? For example. If I save a file 10 times locally even though I don't check in, will every one of those local saves be checked in on the TFS server so anyone on the team can see? Of does it just send to the server the latest saved version of the file when you check in? I'm not looking for it to do this because it wouldn't seem to make sense unless a manager wanted to track your hours or something.
MSDN describes the checkin process over here. It is stated there, that...
... all the included file changes from your workspace along with the comment, check-in notes, and links to related work items are stored on the server as a single changeset on your server.
That means that only the last version of your changes made locally will make it into the changeset, onto the server and to your coworkers. You can save as often as you want beforehand, the server won't notice.
Short answer: No.
Longer answer:
I can't think of any SCM that works that way.
Here's how it works, with pretty much any version control system (the terminology will differ from SCM to SCM, but the concepts are the same):
You start modifying a file.
You change the file as much as you want. When you're done, you commit it/check it in.
The contents of the file at that point in time are what's stored in the SCM. No intervening changes are stored.
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've got a file managed by Visual Sourcesafe 2005 which I have edited. I'd like to check in the file exactly as-is on my box, but VSS always merges it with the file in the repository, breaking my code.
I don't know what I expected to happen...
Is there any way to check the file in without merge shy of deleting the existing file from the repo and adding my copy back in?
I've looked for command line options to no avail.
You could just do "Undo check out" for all files, keeping their local versions on your machine; then again check out this files without getting latest versions from Visual SourceSafe; then check in all of them. In this case history is preserved. You just overwrite latest versions of files without any merge. Seems for me it's what you wanted.
I had the same problem and sorted it out in that way.
I'm putting this answer here, but still really hoping that a better one comes up.
I figured that I can go into the VSS GUI and rename the file to ".old", then add my local file into the repo. It's extremely hacky, but allows me to keep the file history.
Such issue might happen when the file was checked out by multple people and there was a newer version checked in by others after your checkout. (See Four scenarios that merge may be performed #2 of the article for more details.)
I don't see a option in SourceSafe CheckIn command to control that either. If you don't want merge happen, you may exclusively check out the file before editing.
We're finding ourselves unable to open our project in Visual Studio because SVN is adding lines like
"<<<<<<< .mine"
to our .csproj files.
This is apparently something SVN inserts when it has trouble merging files, but we're not interested in merging things as two people can never have the same file checked out.
How do we set Visual SVN to Replace instead of Merge?
Thanks for any help.
It's doing that because SVN tries to preserve whatever changes you've made to your local working copy. Thats a pretty important aspect to the SVN method of version control so I don't know, and doubt, if its possible to do that. I do know you can tell svn to ignore files, but their changes then won't be committed to the repository, nor updated from the repository.
If its a problem, delete the csproj file, then when you update it will redownload the proper version. Do that whenever theres a problem. If it happens quite a bit, then one of the developers is messing with the file.
Past projects I've worked on had a dozen engineers working on the same projects, and we never had constant merge problems with the .csproj files.
What do you mean by "two people can never have the same file checked out"? I think you are misunderstanding how Subversion works - checkout is not an exclusive lock on a file.
Visual SVN uses Tortoise on the backend I believe. when you are in a conflicted situation (i.e. SVN cannot merge the two versions cleanly) you should have the option you should get a pop up where you have the option to either "Use Local" or "Use Repository". If you choose "Resolve Later" you'll get what you are describing.