I have a SVN source controlled project which contains some generation scripts that require changes so they apply to the particular machine. However, I don't want to ever check these files back in. Is there some sort of client side ignore mechanism available in the AnkhSVN client that will prevent me from accidentally checking in these changes?
I tried using some different terms and finally ran across this article:
http://agilemusings.blogspot.com/2008/12/tortoisesvn-ignore-on-commit.html
Adding files to the ignore-on-commit changelist affects all clients so regardless of how you make this change it will apply to both Tortoise and AnkhSVN. Also, this doesn't have any effects on the repo itself so you won't be stepping on any toes if someone else on the project does need to make alterations to these files.
I usually recommend to not-check in these files that are changed locally. You can create a template file instead. You can then customize the buildscript to copy the file in the right place if it is not already there.
Then you can just the svn:ignore setting (Right click Subversion->Ignore->... on an unversioned file), to make sure the file is not accidentally added.
Related
Our projects have configuration files that are checked into source control, essentially as a template, that the developers check out and modify with their local config changes, which shouldn't be checked back in.
Policies are already in place to prevent these local changes from being checked in by accident, but it's still very obnoxious to always have dozens of config files in the Pending Changes view of Team Explorer that I just always have to exclude.
.tfignore only seems to ignore Add operations, not Edits. After some searching I found that some people had success with cloaking the files/folders, but that hasn't worked for me.
The files can't be removed from source control - they exist there for a reason - however I'd really like to not have to see them as pending changes every time I go to check in my work.
Is this even possible?
No, it's not possible.
There isn't a way to ignore detecting the file changes which already been in source control, unless all the developers cloak the configuration files/folders with the workspace mapping, but that seems not available for you case.
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 have been using XCode with subversion for some time now, no problem was caused when I was using it as a single developer (I was using 2 commands only, commit and add).
But now I have to share the code with another developer (who has never used any kind of version control) and integrating/merging the code has become a nightmare. No problem occur when we are integrating/merging .h/.m files but as soon as it comes to ".nib", "xcodeproj" and ".xcdatamodeld" files, we really don't know what to do.
Whenever we try to merge "xcodeproj", project was getting corrupt and merging ".xcdatamodeld" was kind of impossible for us.
So I was wondering if someone can share his/her experience on how to effectively use subversion/git/mercurial with XCode 4.0 in multiuser environment? or share a link, which can explain how to use subversion effectively in multiuser environment.
Thanks.
Are you doing this using Subversion? For 90% to 99% of the files in your repository, the standard Subversion workflow of checkout, edit, commit works well. However, for some types of files such as JPEGS and GIFS simply don't merge well. In this case, you'll have to do it the way we use to in the old SCCS and RCS days: Before you can edit and commit a file, you must lock it.
Locking a file prevents others from editing the same file and committing changes while you're doing your work on the file. It's crude, but it works. In Subversion, you can always lock any file you're editing, but if the file has the property svn:needs-lock on it, it will be checked out as read-only. You have to lock the file before editing it to make it writable, and you're not allowed to commit the file unless it is locked.
So, for those files, set the svn:needs-lock property on it.
You can automatically set this property on all newly added files (depending upon suffix) via setting the auto-properties in your Subversion client configuration.
And, if you really, really want to make sure that all .nibs and xcodeproj and all of the other flies of these types have svn:needs-lock set on them, you can use my pre-commit hook which will prevent these files from being committed unless this property is set.
There is no failsafe way to merge these kinds of files that I am aware of. So you will have to
try to ensure that only one person is changing these files at a time. That won't work always, so just log what you changed in the file with the commit message. Then if there is a conflict, you can manually resolve it by taking the version that changed more of the file and redo manually what the other person did.
That's normally not a big deal, like adding a new source file to an .xcodeproject, or changing the alignment of an element in a .nib. It's becoming a problem if your project is huge or your nib is containing the whole interface. For it to work well (which in practice it does), you need to split up your projects into sub-projects if they grow too huge.
I had the same problem with 2 other developers Xcode with git. Unfortunately, Xcode project files are an XML file, tracks file included in the project as well as setting. I'm not certain, but I think .nib files are also XML files as well. Someone can correct me on that.
Git did a great job at merging the Xcode project file, and never really had any problems with our *.nib files either. The only time we did have a problem is when we both added/removed files with the same names, or someone did a lot of heavy removing and adding of a lot of files.
The only way we solved this was to have each other push ann pull as soon as we added/removed files. So that way the person had the latest files, and didn't add them in their own repository then pull the latest commit which had the same file in it. Or they work adding changes to a file that was removed or renamed.
That is the best solution we found, as soon as we added or removed a file have everyone else in the team pull. Not a great solution btw. However, you should be committing often anyways.
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).
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.