I'm probably reading too much into ignore, but other than not showing up in the list when you commit, are there any other feature/benefits associated with ignoring a file?
It also doesn't clutter your svn status list. But anyway, not commiting files to the repo that don't need to be versioned (e.g. because they are created by the application, or they are settings files) is a pretty useful feature by itself, I'd think.
files to ignore:
files generated during a build (local properties, byte code, etc)
files generated during runtime (log files)
svn meta files
imagine NOT being able to ignore all of this
Related
I believe this question applies to CMSes in general.
I'm using a CMS, Kentico, for a particular web application. The CMS installer generates its own boilerplate project with 10,000+ files, and this project amounts to a runnable web app. Very few of the CMS-provided files are intended for modification. Yet standard practice is to add custom code to the project, and to check the entire project into source control.
I dislike the idea of checking in my entire CMS. I prefer my repository to contain only the code particular to the project, while vendor files are automatically "pulled in" from elsewhere. For example, Visual Studio can restore NuGet packages into a fixed location in the project, and this location can be ignored by version control.
In a way, development with the CMS is dirtier than when using a typical vendor library. Usually your own code depends on a library, while the library is independent from your code. However, the CMS wants to be your app, and your own code interweaves. The CMS requires customization of its own provided files. You can't just "pull in" the CMS files to a fixed location and then ignore that location.
Given this scenario, I'd still like to omit as many of the CMS files as possible. So far, I've settled on this strategy:
Keep a pristine, readonly copy of the CMS-provided files at a standard, local path.
Create a fresh project root directory.
Copy the CMS-provided project file to the project root.
In the copied project file, change the 10,000+ file paths to point to those pristine CMS files, which are external to the project root.
Place only files with custom code into the project root. If a CMS-provided file must be modified, copy it into the project root directory and use that copy.
This strategy sounds good in theory, but it's more complicated in practice. Here are a couple complications:
Changing 10,000+ file paths to "link" in external files turns out to be more than a find-replace operation. More complex mapping is necessary to preserve the pristine project's directory structure.
The web server requires all the files to be in the same directory. Using the project file to link in external files is fine for compilation, but you've split your web root in two.
For the latter problem, it seems the best workaround is to perform post-build copy operations. This is, in itself, more complex than it seems from the outset.
As I write this, I'm starting to feel like I should go ahead and just dump the entire working CMS into my repository. It feels dirty, but it's a hell of a lot simpler. Before I do that, does anyone have any experience or ideas for how I might accomplish my goal?
To restate my question: How can I exclude my CMS's provided files from my version control repository, while still including them both in my project / build script and in my web app root?
Here's another idea for how to accomplish this:
I establish a standard local directory for Kentico DLLs and the Kentico installer, which will not be in version control.
I create KenticoSupport.csproj, a class library of types extending built-in Kentico types, just as they are intended to be extended. This will also contain content, such as JS, CSS, ASPX, ASCX, etc. files. This will be in version control, but it references the central Kentico DLLs, which are not in version control.
I create KenticoBuilder.csproj, a mostly empty project that is mainly a build script. It also contains a few simple *.patch files to modify matching Kentico files, such as Web.config and Global.asax.cs. This is under version control.
Here's what the KenticoBuilder.csproj script does:
Build KenticoSupport.csproj.
Create an output directory that will serve as both a web root and a project directory.
Install / copy the pristine Kentico project files into the output directory.
Apply patches to matching Kentico files in the output directory (mainly to add config lines and custom bootstrapping).
Copy custom DLLs and content from KenticoSupport to matching locations in the output directory.
Build the project at the output directory.
It's complex, but I think it might just work. Thoughts, anyone?
Kentico should hopefully be fixing this soon, with pre-built dlls you can reference rather than rebuilding the entire CMS every time you modify C#.
Until then, have you considered using a Symbolic Links to reference your pristine files? Then just overriding the links with your modified files when need be?
See this other question if you haven't used them before. mklink comes with newer Windows versions (Command-line), but there are a bunch of third party GUI based apps as well.
I came up with an ideal strategy:
Place the pristine CMS files at an external "code libraries" location, and make them read-only for good measure.
Make a copy of the CMS-supplied project file.
Convert all project items to link to the code library's copy, including assembly references. The required link element for MSBuild complicates this, so I wrote a little console app to parse the XML and generate the necessary elements. I also store the path to the library in a property.
At this point, you have a compilable project. The files are all just links to read-only, baseline, CMS-provided files, but the IDE shows a nice directory structure, as if the files were actually in your repository. As you customize, you can replace the links with your own actual files.
However, your website files are now split between two completely different locations. The web server needs them to actually be in the same directory. This is where some scripting comes in handy.
Using your build scripting tool, plug into the post-build event to copy linked files into the project directory. Naturally, you can omit the compiled files. Here's how I did it with MSBuild (thanks to this blog post):
<Target Name="AfterBuild">
<ItemGroup>
<LinkedKenticoFiles Include="#(None);#(EmbeddedResource);#(Content)"
Condition="$([System.String]::new('%(FullPath)').StartsWith('$(MY_LIBRARY_BASE_PATH)'))" />
</ItemGroup>
<Copy SourceFiles="%(LinkedKenticoFiles.Identity)"
DestinationFiles="%(LinkedKenticoFiles.Link)"
SkipUnchangedFiles='true' />
</Target>
Optionally, plug into the cleaning event to remove those files. I used similar MSBuild syntax to delete the files, and because it leaves behind empty directories, I remove empty directories, too. (Thanks to this answer.)
<Target Name="BeforeClean">
<ItemGroup>
<LinkedKenticoFiles Include="#(None);#(EmbeddedResource);#(Content)"
Condition="$([System.String]::new('%(FullPath)').StartsWith('$(MY_LIBRARY_BASE_PATH)'))" />
</ItemGroup>
<Delete Files="%(LinkedKenticoFiles.Link)" />
<ItemGroup>
<Directories Include="$([System.IO.Directory]::GetDirectories($(MSBuildProjectDirectory), '*', System.IO.SearchOption.AllDirectories))" />
<Directories>
<Files>$([System.IO.Directory]::GetFiles("%(Directories.Identity)", "*", System.IO.SearchOption.AllDirectories).get_Length())</Files>
</Directories>
</ItemGroup>
<RemoveDir Directories="#(Directories)" Condition="%(Files)=='0'" />
</Target>
Optionally, make your source control ignore the site / project folder, to avoid checking in the temporary, copied site files.
I'm considering using LESS for CSS development with server (or development) side processing, but I can't decide if I should keep the generated CSS files in version control. There are plenty of solutions with hooks, but this adds software dependencies to the server. A hook could just be added locally so staging and production areas on the web would get the same files. So, the question is:
Should generated CSS files be included in version control or not? Please keep in mind that some frameworks require a CSS file to exist for a particular reason (i.e. WordPress themes require a style.css file in order to be recognized).
When I say 'considering using LESS', I mean it becomes a requirement. New developers would not have the option use vanilla CSS after the choice is in favor of LESS.
Checking in derived artifacts is almost always sub-optimal.
I vote no to checking in the .css. It's only a matter of time until one of your peers or successors checks in an edit to the .css and not the .less. Then when you change the .less the prior change is lost.
You've pretty much answered your own question. It depends on how you deploy your website.
If the server is just going to pull directly from the Git repository:
1) It needs to have software installed to generate CSS from LESS.
2) or you need to include the CSS files in the repository.
If you're not pulling straight from the repository on your web server, you could have a build script that pulls from git, generates CSS, and then transfers the content to the web server(s), possibly excluding unnecessary files from the transfer.
In my opinion, Git should be used to keep all of the source for a project, and none of the "derived artifacts" (as mentioned by #thekbb). Developers need to have all tools installed to generate those derived artifacts during development and test. For deployment to test and production servers, an automated build server should take the source and create just the files needed for distribution.
In the case of software development, you'd have a Makefile with .C and .H files (for example) in your Git repository. Developers and the build server have a compiler installed that will create an executable or compiled library. When the files are packaged for distribution, the source code is not a part of the archive.
For web development, you have source files like original graphics, HTML templates and LESS files. Developers and the build server can run scripts to generate the site assets (CSS from LESS files, static HTML pages from templates, flattened images in multiple sizes/formats, etc.) When the build server deploys new builds, it copies just the files needed by the server, excluding the source graphics, templates and LESS files.
If there are people that need to review the site content, they should do it on a staging server. If that's not possible, the automated build server can create a ZIP file on an internal server that they can download for review.
Should generated CSS files be included in version control or not?
In theory they should not, but for practicality, I do usually checks in the generated css file. The reason is that it simplifies deployment since I do deployment using git; I would not need to have a less compiler installed on the server and usually not even on the machine I'm deploying from (as opposed to the machine where I'm developing on). Doing this could be useful if you have separate developer and deployer, but can sometimes also be useful even if you're deploying yourself.
Now, there are drawbacks on doing this:
You can't use git add --patch (or you really need to be very careful when doing so)
You should not modify the .css directly; instead I usually use a secondary .css file to do minor modifications without modifying the primary .less or .css file. You can also compile .less file straight into a minified css, to make it less tempting to modify the generated css.
Developers have to set up their machine to use automatic recompile tool (like SimpLess or Less.app), so the .css file is updated as soon as they save to the .less file. Without automation, you'll run into risk of the css not matching the checked-in less file.
I would not do the same when compiling from .C and .H files though, because the generated binary for those are platform specific, and also .less/.css file is usually a very small part of a larger web project so the space overhead of the additional file is small.
Good question. If you can absolutely guarantee that the CSS file gets updated when the LESS gets updated then perhaps yes - as per #Scott Simpson's comment. I suspect that this would be difficult to guarantee and what happens when the new developer get's a copy of CSS the day when they are out of sync? Also, of course, and I hadn't originally thought of this, what happens if the new developer then makes updates to the CSS file rather than the LESS?? If the CSS has to be built and isn't part of archive I can see less problems.
I would say yes -- because what happens if you want to add a developer to your workflow and they don't want or need to build .Less? It would be helpful for them to have access to only the generated file.
I need to know what folder names are commonly used by Version Control systems. Many VCSs will create a hidden folder, usually in the top level of the source tree, to store the information that they use.
So far, I only know that Git uses .git/ and SVN uses .svn/.
What are the folder names that other popular VCSs use?
We could probably divide the VCSs into three groups:
Special Subdirectory in each directory
CVS
Subversion (.svn)
The advantage of this is that each directory in the working copy is a self-contained working copy: you can copy it out somewhere else and it will still work. The obvious disadvantage is the clutter. Using automatic tools to scan over one of these working copies need special filtering or they will return spurious results.
Single special directory for each working copy
Mercurial (.hg)
SVK
(Maybe Git, I'm not sure?)
Special file system support
ClearCase (dynamic view is a mounted FS; snapshot view is more similar to the single directory case)
Mercurial = a single .hg directory
I've just started using Subversion with ASP.NET web applications via the VisualSVN IDE plugin. There are a bunch of files which Visual Studio automatically generates so I don't want to version control these since they're not really part of the codebase and not required to build.
Does anyone have a definitive list of the main files that should be ignored when commiting to Subversion from an ASP.NET Web Application? and how would I go about ignoring these files. If possible I'd like to set it globally so that I don't have to keep doing the same thing for every ASP.NET Web Application that I write and create a new repository for.
Answers
A list of files to ignore as submitted in the answers below,
bin
obj
*.exe
*.pdb
*.suo
_ReSharper.*
*.user
General concensus seems to be that these should be ignored on a per project basis at the creation of the repository. They will then be ignored by all users using the repository.
Not really 'definitive', but I always ignore .suo and .user files and the bin/ and obj/ directories
Here's my ignore list from TortoiseSVN. VisualSVN requires TortoiseSVN and uses its settings.
bin obj *.exe *.pdb *.suo _ReSharper.* *.user
I haven't committed any unwanted (or not committed any wanted) files with this setting.
If you have any WCF service references then you only need to include the files Reference.cs and Reference.svcmap for each service reference.
The AnkhSVN plugin for Visual Studio has a list of files to ignore automatically and will only commits the files needed.
At least that's how I find it. It's taken me a few attempts at setting up the repository correctly but with AnkhSVN only commits a subset of he files that TortoiseSVn wants to commit. If ignores files recompiled on every Build for example.
Depending on your situation, you might want to keep the Web.config out of revision control as well. Different developers might require different configuration files for a website.
I'd recommend setting up a separate directory in your repository with a reference configuration file for the website and ignoring *.config on the actual project directory.
Additionally, to cover case sensitivity issues with "bin", I had to add [Bb]in to mine. So I have:
[Bb]in obj *.exe *.pdb *.suo _ReSharper.* *.user
Also, this link explains how to handle project specific excludes as well so that others get the same exclusion behavior only for the same project when they check it out:
http://svnbook.red-bean.com/en/1.1/ch07s02.html
I used the svn:ignore property on a particular directory to exclude a certain set of files that were copied into there (but I still wanted the directory itself in svn).
Use VisualSVN to do the initial "Add files to repository" and it automagically ignores the stuff you don't want-such as suo files and the bin/obj folders.
I noticed that Eclipse (Flex Builder) generates hundreds of metadata files. Should I check them into my source control? They seem necessary, because if I delete them Flex Builder just opens up an empty workbench...
Some of these files plainly do not belong in source control (like .history files and some cache files). If I delete them my project opens up again without a hitch. But the list is long and there seem to be no clear separation between folders that contain files that belong in source control and those that do not.
I can't just shove them all into svn, even if I were to ignore the inefficiency, because Eclipse generates new ones constantly, with different names, which in turn also seem to be crucial for the project to load.
Can someone please enlighten me?
Don't check in the hundreds of metadata files. If you want to be able to check out the project in a way that it can just be imported, then check in:
.actionScriptProperties
.project
.flexProperties
And "html-template" and "libs". As Christian says, any resources you depend on. I usually keep those as separate Flex Library projects though.
I generally put all of my source code under src, and I check in src and all of its descendents. If my project relies on any external dependencies (e.g., the Cairngorm SWC, as3corelib, etc.), Flash/graphical assets, stylesheets, or resource files, I check those in, too. But I don't check in any generated (bin-*), intermediate or IDE-specific stuff, because having that stuff in source control doesn't seem to provide much practical benefit, and in my experience has only caused me headaches; in general, I check in the most minimal set of whatever I'd need -- given a clean FlexBuilder installation (or none at all -- for example, if I were compiling instead with mxmlc or compc) and an empty project -- to build the project successfully.
Most of the eclipse project files, like .project, .properties, everything in .settings, can go into your source control. As long as the files don't have user-dependent settings like file paths or local urls, you should be fine.
One method we use is creating local property files that don't get used in SCM, but are included in the ones that do. I.E an ant build file including a local.properties file which has local metadata.
What if the .actionScriptProperties, .project, or .flexProperties have user-dependent stuff in them? Typically this will be url or path information. What's the best practice way of externalizing this? I tried creating path variables, but this only works obviously for paths. Not for things like hostname, etc.