I'm working in Visual Studios 2010 and Ankhsvn.
I need to exclude a few of my files from being Committed (which I did through ignore-on-commit in the Change log.)
How do I exclude the files from being changed when I update?
I've tried adding the svn:ignore property, but I keep getting errors thrown. Maybe I'm using it wrong... It shouldn't be this hard to completely exclude files.
svn:ignore is a property on a directory that you set to specify that the given resources shouldn't be in version control - which doesn't sound like what you want. If the file is already under version control, SVN will always try to process it. The effect you're after (restricting svn operations to a given subset of files) can be achieved using the --changelist option. You can use svn changelist to create lists of files, then suboptions to add and remove files from that list, then you can pass that changelist to svn up to limit which files get processed.
Related
When using Git and the Git GUI, I'm used to highlighting one or more lines, right-click and use the selection as what I want to check-in. This way, I can for example create two check-ins from the same file: say fixed typos (not interesting) and new functionality (interesting for someone that checks the version history).
In Visual Studio, I can only check in the entire file, but not specific lines. In order to do this, I could:
copy the server-version and my local version to Notepad++ as two files,
compare the two files,
copy the selected changes to my reverted local version that I want
to check in,
then check in the current changes,
and finally copy all the remaining changes to my local version so that all
changes are back in my local version. (rinse and repeat for all separate changesets)
This is... not ideal.
Is there a way (perhaps via a client-side plugin) that I can select a part of a file to check-in, but leave the remainder un-checked in?
You basically want to do a version control in other words. There are lott of them like git,SVN they are designed to do what you want.
I am trying to use subversion and am having a tough time. The documentation is unclear at times. Basically I am trying to figure out how to merge but that causes conflicts because of files that should never have been included in the repository.
I issued a svn import command. That put the *.suo and bin and obj folders in the repository. I then added the svn:ignore command to the top level folder of each dll to ignore *.suo, *.user bin and obj. But this still causes problems because compiling the project (50+ dlls) creates these folders and since they existed in the repository before this causes conflicts.
So I presume that I need to create the repository without these files. But I can't use the svn:ignore command without a working directory as far as I know. Maybe the tortoise gui can do it but I am trying to learn the tool itself. If it can not do this I would like to know.
Thanks
JM
First rule of merging: always have a pristine checkout as the merge target. That means, only versioned files in the checkout, no modified, added, deleted, unversioned or ignored files and folders. I ensure this by using TortoiseSVN's Cleanup command, ticking everything:
From what I understand about your question, it seems you've SVN-Added-and-Committed some files and folders that should have been svn:ignored in the first place. So, using TortoiseSVN, select the files, and choose TortoiseSVN -> Unversion and add to ignore list -> *.ext:
Do the same for the folders, but Delete and ignore by name instead.
What this does is an svn deletefollowed by adding an svn:ignore property on the containing folder with the file/folder pattern set.
And then, commit the changes.
After that, do the SVN Cleanup as detailed above to delete the now-ignored files and folders, and then conduct your merge.
It's worth noting that VisualSVN automatically adds the svn:ignore patterns for projects newly added to a solution.
Hope this helps.
I found the answer was to use the global-ignores in the config file which can be found in:
C:\Users\%User%\AppData\Roaming\Subversion\config
I tried using the svn:ignore and that appears to work in the short term. Try to do a merge and it causes conflicts. The config file should look like this:
[miscellany]
global-ignores = *.suo *.user bin obj
But the global-ignores is really a local global-ignores. It is local to your machine but global to all your commands / repositories. Anyone else doing any imports will need their file updated or any projects they import will suffer the conflicts.
Are you using Visual Studio? Then, use AnkhSVN. This will do several things:
It will automatically not commit special user specific VisualStudio files that are causing you so much heartache into your repository.
It allows you to use Subversion from inside of VisualStudio. No need for a separate client.
It will make sure to use _svn folders to store Subversion working directory information rather than `.svn.
Also, consider a pre-commit hook that will prevent users from committing these types of files. I have one that I've used for years. It can be used to prevent users from committing any files that end in *.suo, .user, or directories called bin and obj. This makes sure that other developers in your group don't do nasty stuff.
There are a number of files in my database project that AnkhSvn isn't committing to the repository. To clean things up using Tortoise, can I safely add them all to the ignore list?
Projectname.dbmdl
Projectname.dbproj.schemaview
Projectname.dbproj.user
Sql\debug\*
Sql\release\*
Indeed, add those to the ignore list. AnkhSVN doesn't need that, because Visual Studio tells Ankh what files should be source controlled (and it ignores the rest).
They are all user files and/or generated. See linked questions for more info about .dbproj.schemaview and .dbmdl files. The rest speaks for itself.
I would like to make a backup of my project, but the folder now exceeds 6.6 GB mainly through extra libraries like boost etc, but even if I just select the folders with my sources, I end up with big files like: .ipch, .sdf and potentially others. To make matters worse I use eclipse to code and VS to compile, so that adds to the mess, although I have the impression that only VS creates big files.
In case shit hits the fan I would like to be able to unpack one archive, and have everything in there like the project settings and solution files, and the sources so that I can easily open it again in VS. I can live with having to re-download boost or other third party libs.
How do you tackle this problem and do I need to preserve file like .sdf?
Answer:
Thanks for all the tips. I will now adopt the solution proposed by LocustHorde because that seems to fit my needs best. I simply want one file that I can take offsite as a safe backup (and I don't want to use an online service). Storing all versions of all files doesn't seem to work towards smaller and simpler and it would be a bit overkill in this case, although I will look to install some version control system because I have no experience with them and I would like to get some...
Final Answer
After having a good look I found that dishing out which files had to be ignored by the winrar archiving was still a hassle. I finally ended up installing Git out of curiosity and liked it. So I now have some of my projects in a local repository. From eclipse I can easily mark files and directories for being ignored, and to make a backup I use git-extensions to clone the repo. I still need to look at purging old versions, which isn't very userfriendly in Git, but seems to be possible at least and then i will just 7zip the folder up. In the worst case I just delete the git database and I just have the last version of my source files. Or maybe I can checkout to another directory. We'll see.
First: Instead of doing a backup, I would strongly recommend using a version control system (VCS) like Subversion, Mercurial, or Git. This is the professional equivalent of a backup, except it maintains every version of every file—not just a copy of the latest version.
Even with a VCS, you will still need to decide which files to check-in to the VCS, and you don’t want to back up files that can be easily re-generated.
For my projects, I generally don’t check-in:
Generated executables (the output in the Release, Debug, x64\Release, and x64\Debug directories).
Pre-compiled headers (the ipch folder)
The browsing database (sdf files)
All of these things can be re-generated by rebuilding your project. If you are working as part of a team, you probably shouldn’t check in:
Your personal settings (.suo)
You can always re-create this if needed.
A particularly nice way to backup your stuff is to put your source in a revision control system. I am using git sometimes, and other times mercurial. Using git I can ignore the files that should not be backed up, by adding them to .gitignore:
Debug
Yokto.sdf
Yokto.suo
*.filters
*.user
ipch
Release
Yokto.opensdf
*.opensdf
*.sdf
With git I can set up a backup repository on a network drive and simply push to it every now and then.
you can write a simple script (batch file) that only zips the types of files you want. suppose, you want to zip all your .aspx, .cs, .config, .xsd files only,
suppose you have winrar installed in your c:\program files\winrar
and your project is in c:\project\MyBigProject
then, just open your notepad, copy paste this, and save as "script.bat" (dont forget the double quotes while saving, you need to save it with double quotes, so that notepad saves as .bat extention instead of .txt)
so to backup (in other words, to zip wanted files) :
"C:\Program Files\WinRAR\rar" a -r0 -ed MyBackup.rar c:\project\MyBigProject\*.aspx,*.cs,*.xsd,*.config
the syntax is like this:
"path to winrar folder" 'switches' "Name of completed rar file" 'folder to zip'
just make sure the paths are in proper order. the "a -r0 -ed" parts are switches, and you can find out all about the switches here:
http://acritum.com/winrar/manual/index.html?html_helpswitches.htm
I use the "Ignore files" switch (http://acritum.com/winrar/manual/index.html?html_helpswxa.htm) to ignore all files and folders that I dont want (with wildcards) and My project is about 86 mb, when It gets compressed just with code files, it comes up to 6mb.
its the best way to do it really. If you need more help, please ask!
edit: Also, Look into SVN (its free!) - I use svn too, and its really helpfull. there is even a free tool called AnkhSvn to integrate into visual studio. its just fantastic!
Doing a "clean" before archiving removes most of what you don't need.
Edited to add:
Of course a version control system is essential for any ongoing project, but that's not what he's asking.
What are the *.FileListAbsolute.txt files for that Visual Studio generates? They keep cluttering up my searches. Such as when I search for *.csproj for adding projects to a .sln.
Does Visual Studio use them? Is there any way to make it not generate them?
The FileListAbsolute.txt file contains the list of files built in the current build and in prior builds, and is used during a Clean and Rebuild to figure out which files to delete.
The file is necessary because in certain situations, such as a project that has been renamed, you want the Build system to be able to delete the older name.
I know this is an older post...but I had this same issue and it turned out that I had accidently checked these into source control and not checked them back out, leaving them read only. The solution was to remove them from source control.
It tracks files to be deleted upon clean. From Understanding the Clean target:
[T]he common targets implement an honor-system method of tracking the output of "the last build". Well-behaved targets emit their outputs into an item named #(FileWrites), which is serialized to $(CleanFile) in the obj directory (it ends with .FileListAbsolute.txt) in a target named _CleanRecordFileWrites. Clean can then read that list and delete files in it during a subsequent MSBuild invocation.
Im not sure why it's generated and am researching that now. VS writes to these files each time you compile. You can delete all of them and it will regenerate when you compile. (Use caution if you use svn and don't delete the svnbase files)