Hi I am relatively new to Maven and intelliJ IDEA.
While trying to import the Maven project, IDE is asking for adding *.iml files to SVN control.
I wanted to know what does it mean ? and what are the merits and demerits of doing so?
The iml files are used by intellij to store module specific settings and other information relating to the module. Usually teams do not add *.iml files to svn. Typically these files change rapidly, and for no important reason, meaning that if you perform something as simple as a search you'll change the iml file and you'll have a difference with the repo that'll need to be submitted or reverted, and you'll always be in this position. Plus, if a developer does check in the iml, the next developer will have their personal settings overridden whenever they do an update.
Adding files to svn (subversion) is done to maintain a history of a project and to share source files amongst a team. Most teams don't want to share intellij's personal module configuration.
Related
I've been having some difficulty with exclusions in SonarQube. I haven't really seen this particular situation posted here, and following some other solutions suggested in exclusion-related questions has not solved the issue. Any insight would be really appreciated.
I've been working with an engineer on filtering the files SonarQube is analyzing from their project during build time. Their solution is being built via a vNext build, where TFS and the build server are hosted on-prem. SonarQube is also hosted on-prem. The build is using the Sonar components included with vNext for the analysis. The project is primarily C#.
The solution consists of mostly projects exclusive to that solution, but there a few projects references that are part of another app entirely. Because of this, the workspace mapping has to get files from 2 separate parts of source control. Also, because of the way the solution is looking for the projects (based on the properties of the solution file itself), I have to map the source control files in a specific way. At a high level, the workspace on the build server looks something like this:
In the sonar settings file, the working directory is set to the Build Source Folder
The engineer wants to exclude code files from specific directories from analysis. For example, they want to exclude all cs files from folder X within B.Srvc. So, the directory would be Build Source Directory/B/Source/B.Srvc/X. Based on the exclusion instructions found on SonarQube's website, it sounded like I just needed to do something like this:
sonar.exclusions=Build Source Directory/B/Source/B.Srvc/X/**/*.cs
When I did that, it still analyzed the files within that folder. I tried various other combinations of patterns like:
sonar.exclusions=Build Source Directory/B/Source/B.Srvc/X/*.cs
sonar.exclusions=**/X/**/*.cs
sonar.exclusions=B/Source/B.Srvc/X/**/*.cs
sonar.exclusions=**/B/Source/B.Srvc/X/**/*.cs
I've even tried giving the complete directory path (so, C:/agent/_work/25/src/...) but that did not work either.
Very broad exclusions like **/* Name *.cs work perfectly fine, but if I want to start excluding files from certain directories, I can't get anything to work.
I feel like I'm missing something really basic, but I just can't figure it out. I've been trying to solve this issue for awhile when I have time, but I haven't made any progress. If anyone could provide any insight, I would really appreciate it. If you need any additional information, let me know.
In the SonarQube interface, look at one of the files you want to exclude. At the top, you will see the file path as SonarQube understands it. It is this path that you want to use when you enter your exclusions through the UI not the analysis settings.
Because of the structure of exclusion properties, they are very, very difficult to set up correctly in analysis properties. That's why doing so is not documented.
Instead, you should enter exclusions through the UI.
Our company currently uses TFS for source control and build server. Most of our projects are written in C/C++, but we also have some .NET projects and wouldn't want to be limited if we need to use other languages in the future.
We'd like to use Git for our source control and we're trying to understand what would be the best choice for a build server. We have started looking into TeamCity, but there are some issues we're having trouble with which will probably be relevant regardless of our choice of build server:
Build dependencies - We'd like to be able to control the build dependencies for each <project, branch>. For example, have <MyProj, feature_branch> depend on <InfraProj1, feature_branch> and <InfraProj2, master>.
From what we’ve seen, to do that we might need to use Gradle or something similar to build our projects instead of plain MSBuild. Is this correct? Are there simpler ways of achieving this?
Local builds - Obviously we'd like to be able to build projects locally as well. This becomes somewhat of a problem when project dependencies are introduced, as we need a way to reference these resources or copy them locally for the build to succeed. How is this usually solved?
I'd appreciate any input, but a sample setup which covers these issues will also be a great help.
IMHO both issues you mention fall really in the config management category, thus, as you say, unrelated to the build server choice.
A workspace for a project build (doesn't matter if centralized or local) should really contain all necessary resources for the build.
How can you achieve that? Have a project "metadata" git repo with a "content" file containing all your project components and their dependencies (each with its own git/other repo) and their exact versions - effectively tying them together coherently (you may find it useful to store other metadata in this component down the road as well, like component specific SCM info if using a mix of SCMs across the workspace).
A workspace pull wrapper script would first pull this metadata git repo, parse the content file and then pull all the other project components and their dependencies according with the content file info. Any build in such workspace would have all the parts it needs.
When time comes to modify either the code in a project component or the version of one of the dependencies you'll need to also update this content file in the metadata git repo to reflect the update and commit it - this is how your project makes progress coherently, as a whole.
Of course, actually managing dependencies is another matter. Tons of opinions out there, some even conflicting.
I have several projects which use code from a large set of component libraries. These libraries are under source control.
The libraries repository contains all the libraries used by all my projects and contains multiple versions of multiple libraries. Each library/version pair lives in its own folder. Each of my projects identifies the specific library/version pairs it needs through the folder paths of the references in its project file.
For example $(LibraryPath)\SomeLibrary\v1.1.5
Please note that the libraries repository is only ever added to. No changes are made to stuff already in the repository. Ever.
I have been of course been able to configure my build plan to pull the libraries repository to a libraries subfolder of the working directory. So far so good. However, using the auto branch management feature of Bamboo, this setup means that the libraries repository is cloned for each and every branch in all projects.
Not funny. No, really, not funny...
What I would like to do is:
pull the libraries repository in each build plan
but pull it to a fixed location that is the same for all build plans
it doesn't have to be an absolute path
but it does need to be outside the working directory of the current build plan to avoid unnecessary duplication
Unfortunately the Checkout Directory of the Source Code Checkout configuration task in a Bamboo build plan doesn't allow me to specify either an absolute path or a relative one that goes "up" for one or more levels from the working dir. The hint text explicitly states "(Optional) Specify an alternative sub-directory to which the code will be checked out." And indeed, specifying something like ..\Library gets punished with the message "Checkout to parent directory is forbidden".
I have seen information on the "artifact sharing" feature of Bamboo. This will probably work, but it seems like overkill for what I want to achieve.
What would be the easiest and least complicated way to achieve my goal using Atlassian's Bamboo Continuous Integration?
Out-of-the-box alternatives are welcome, but please don't direct me to any products that require intimate CLI use and/or whose documentation assumes (extensive) knowledge of 'nix and/or Java setup. I am on Windows and spoiled rotten by powerful (G)UI's.
I have the same problem - with a repository weighing in at around 2GB.
I'd like to simply "git checkout myBranch" and "git clean -fxd" instead of cloning every time (which should save a lot of time and disk space). However I also like Bamboo's automatic trigger with new branches showing up.
Like the OP, I'd love to be able to put "..\SharedDirectory" in the "CheckoutDirectory" for the
"Source Code Checkout" task but it won't let me go out above the \JOB_KEY\ folder
One possible solution is: replacing the "Source Code Checkout" task with the two git commands above. That way I can specify exact when/where/how to do the checkout. I think there may be problems with the initial checkout in this case - but once that is solved, all subsequent branches would use the same shared folder, and no more pulling down 2GB every time.
Apple has introduced a new project-related type of file in Xcode 5: "xccheckout".
This file is located in the ".xcodeproj/project.xcworkspace/xcshareddata/" directory, and it seems that it is related to the project's version control system.
An example file is here: http://pastebin.com/5EP63iRa
I suppose that this type of file should be ignored under VCS, but I'm not sure.
So here are the questions:
Should "xccheckout" be ignored?
What is its purpose?
You should check in an Xcode 5 .xccheckout file; in general, files in xcshareddata should be committed.
An .xccheckout file contains metadata about what repositories are used in a workspace. For a single project in a single repository that doesn't make much difference. But if you're using a workspace that has multiple projects from different repositories, the presence of an .xccheckout file in the workspace allows Xcode to know what all of the components that make up a workspace are and where to get them.
The *.xccheckout file contains VCS metadata, and should therefore not be checked into the VCS.
On the other hand: checking in this file will probably not create merge difficulties or other problems.
If you want to ignore this file (which I recommend) you should add this line to your project's .gitignore:
*.xccheckout
Abizern's solution will not work for projects inside a workspace. Because, when you use a workspace, the path to the *.xccheckout file will be: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. And it actually ignores more than you would want.
Edit:
This file exists for managing Xcode's knowledge of the possibly many VCS systems in your project, see Chris Hanson answer. For > 99% of the projects the .xccheckout file is configuration overkill.
It depends. The file contains references to the remote repository you are using. If you are using a centralized VCS such as Perforce or Subversion, everyone's remote repository will be the same and so you can and should check the file in.
If you are using a distributed VCS such as Mercurial or git, but using it as though it were a CVCS (in other words, everyone cloned from a shared repository directly to their personal workspace on their machine) then you still might want to check it in.
However, if you are using a DVCS with everyone having their own remote clone, for example using GitHub in it's standard usage pattern, you DO NOT want to check this file in. If you did then your Pull Requests will be asking for your repository settings to get copied into everyone else's xccheckout file, but your repository settings will be different from everyone else's because you are all using different remote repositories.
Yes, the Project.xccheckout file should be committed to your repository. Xcode uses this file to tell others who open the workspace the entire list of source control repositories used by the workspace and the location of the working copy relative to the workspace, whether those repositories are Git, SVN, or both.
When you open the workspace, Xcode uses the Project.xccheckout file to notify the user that there are other repositories forming part of the workspace, and asks which should be checked out. When checking out additional repositories, Xcode places the working copies in the same workspace-relative folder structure as they were when the Project.xccheckout file was generated.
As Chris Hanson said, it probably doesn't matter for a single-repository, one-project workspace, but for more complex affairs it'll be very handy indeed.
You can find out more about this in the WWDC 2013 session video Understanding Source Control in Xcode; the relevant portion starts at about 15 minutes.
This is what I have in my .gitignore for Xcode.
#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/
It keeps anything that relates to the local state of the way the projects looks for me out of the repository.
The xccheckout file is under here so it is not tracked on my system by default.
Xcode has gotten better and separating out what needs to be shared and what needs to be kept locally. For example; these lines will ignore the default build schemes, which is fine because you can mark specific build schemes as shared, and they are put in a directory that is not ignored.
Breakpoints are ignored, but you can mark specific breakpoints as being shared across projects and they are also placed in a directory that is not ignored.
We are working on a large project. The project has multiple external sites and multiple internal sites all stored in Subversion.
The external sites allow a customer to make requests of various things we provide, pay utility bills and more. We decided to break many of these functions apart because most work completely different than the others. So this is one Visual Studio solution with the WebUI and the database layer broken into two projects each. For instance, utility billing has a Utility.WebUI project and a Utility.Domain project. All DB/business logic is kept in the domain project.
The internal sites bridge the gap between the back-office system (IBM i) and the web database. Also will replace/enhance some of our older RPG programs. In theory they should use the exact same database logic that the external sites use because they access the same database right? What is the best way to reference these projects from a different solution? Should I just add a reference to the dll or should I import that project from the external application solution into the internal application solution?
This comes down to that we have two developers working on this project. Myself, I do most of the back-end coding. The other developer does most of the GUI coding. So we need to make sure that this project works on multiple workstations.
Does this make sense? Any thoughts?
Use the svn:externals property to reference the shared project into your project(s).
You have to choose between 1) referencing the directory containing the shared project's source code (i.e. where the csproj and cs files are located) or 2) referencing the directory containing the shared project's build output (assembly / dll).
I normally prefer method 1) since it makes modifications to the shared project's source code easier (you can make changes without having to open the shared project's solution in a second instance of Visual Studio). If you don't intend to make changes to the shared project often then method 2) might be better. It reduces compile time and prevents accidental modifications of the shared project's source code. Both methods are fine - matter of taste.
It is recommended for both methods that you version your shared project. i.e. create tags with version numbers and reference the tags, not the trunk. When a new version of the shared project comes out you can update the svn:externals property of your other project(s) with the new version number, run "svn update" to download the new version of the shared project, and recompile. This works especially well if you have a build server for the shared project that does the tagging for you automatically.
I think you can use a sort of "commons" solution that contains the common projects and then refer to these projects in you main solutions using SVN external pointing to the project folder in the SVN trunk.
Commons SVN repository must follow the suggested repository structure (trunk, branches, tags) to have always stable commons projects.
In this scenario you can consider to use a dependency management tool, such as NPanday or NDepend, where you must declare to which version of which assemblies every project depends on; using these tools you can have a local repository (such as Artifactory or Nexus) of binary assemblies to refer to, or choose to use SVN externals to refer directly to source code.