Creating a patch is very easy in SubVersion, With Tortoise, you right-click and select Create Patch. But for the life of me, I can't find this functionality in TFS. Is this possible?
If not, what's the standard way to submit patches in open source TFS hosted projects (a la CodePlex)?
tf diff /shelveset:shelveset /format:unified
Edit: This writes to standard output. You can pipe the output to a file.
For more options, see Difference Command.
Because TFS doesn't natively support patch files, the most common thing I see people do on CodePlex is simply zip the modified files and upload the zip. The project coordinator then does a diff against their own checkout.
However since CodePlex also supports TortoiseSVN, more and more people are using that to create their patch files.
I wrote a blog post about a similar issue where I used the TF.exe command and 7Zip to create a TFS patch file that could then be applied on another TFS server or workspace. I posted the the Powershell scripts at Github, which can be used to Zip up any pending changes on one workspace and then apply them to a different server. It would have to be modified to use a changeset instead of pending changes, but that shouldn't be too difficult to accomplish.
Related
we are using Redshift as our EDW and we have quite a bit of tables and view there. at the moment we keeping all DDL's in our organisation's knowledge centre, but this is basically copy and paste and not very smart. is there any other option that is quicker better to do so?
thanks
Not very sure what you meant be "copy and paste" but you can try to put all the scripts in a github/ SVN repository and make sure that all the DDLs actually get fired using the scripts from the repo.
We did this using git and Jenkins (and little bit of Shell programs to do the code checkins and checkouts). We blocked all the users from running DDL statements and the Jenkins job would just pull the latest scripts from the repo and deploy it automatically from the RC (release candidate) branch of the repo.
If you need to export the DDL scripts out from the system you can use the script provided by the AWS folks,
https://github.com/awslabs/amazon-redshift-utils/blob/master/src/AdminViews/v_generate_tbl_ddl.sql
If you want to automate the checkin process to some code repository, you can build a wrapper python code using this code.
I'd like to check in assemblies to TFS source control after successful project build on TeamCity. Are there any elegant and easy way to do that?
I can create a command line step and run tf.exe with parameters, but then I need to provide credentials to connect to TFS, map the directories and finally do the check in.
The second option is to set up the powershell step, and use one of the cmdlets, but this requires installation of cmdlets on the build machine which I don't want to do.
Have you got any experience in such case? Maybe I can use the credentials used by TeamCity to get the sources, and do not map the directories but use the downloaded structure / sources?
This answers your question but it is not normally a good idea to commit binaries to your source control. You have a couple of choices.
Create a nuget package manually:Nuget Packages can be stored in a
shared folder. You can manually create a package in 5 minutes.
If your other projects are built using teamcity, check out artifact
dependencies in teamcity.
TF.exe commandline tool is the best feasible option for this scenario.
I want to ignore files on Team Services version like web.config or app.config.
Because they are related with user and local db's. So I wanna ignore them when I check in all solution.
I searched little bit but all informations are about local servers. So I can't apply this solutions.
For newer versions of TFS (which includes VS Online), the preferred approach is to use a .tfignore file.
You simply check-in a .tfignore file and TFS uses that to determine which files/paths/extensions/etc to ignore and not include in TFS.
You can read more about tfignore files here: http://msdn.microsoft.com/en-us/library/ms245454.aspx#tfignore
Simply add files to store details outside of web.config and then Undo the Include in the Pending Checkins, original answer here: https://stackoverflow.com/a/3883663/585248
This answer relates to having exclusive checkouts ... if you use Local Sever then you can use ignore files. Exclusive checkouts you would need to set it to Server and try the solution from the link above. Tested and works.
What is the easiest way to apply the changes from a specific changeset from one TFS instance on another instance?
What I want is to get some sort of patch file from instance A that I can apply to instance B. Since there are two different instances, a traditional branch/merge approach cannot be used. And as far as I know, TFS has poor support for patch files in the traditional Unix-sense.
Do I really need to inspect a changeset on instance A and manually zip the relevant files which I can then extract into the source tree of instance B?
Turns out that the "patch" route was a dead end due to lack of support in TFS. The solution we ended up with was to perform a nightly job which basically does the following:
Get all code from remote repo with a read-only user.
Overwrite all content of a separate branch in our repo with the content from the other.
Perform a merge from that separate branch to the main branch whenever we want to bring their changes into our main branch.
This answer explains how to create a patch file using the tf diff command. However, there is no built-in way to apply that patch file to another instance or branch. I have not seen any third-party tools to do so either.
I wrote a blog post about a similar issue where I used the TF.exe command and 7Zip to create a TFS patch file that could then be applied on another TFS server or workspace. I posted the the Powershell scripts at Github, which can be used to Zip up any pending changes on one workspace and then apply them to a different server. It would have to be modified to use a changeset instead of pending changes, but that shouldn't be too difficult to accomplish.
I'm trying to get continuous integration working using Hudson, Maven & Perforce (with an scm poll used to trigger each build)
One of the requirements is to automatically update POM snapshot version numbers following each successful build.
This is trivial using the Maven release plugin, but the act of checking in the newly versioned POMs triggers another build - which continues ad infinitum.
Is there any way of checking in version updates without triggering another build? There doesn't seem to be any way of excluding specific user checkins, specific changelists, or specific files when the scm poll makes the decision to rebuild.
This seems like a basic requirement - been doing it for years using Cruise Control / Ant / Perforce,
Cheers,
Mark
I have been contemplating a move to Hudson, but the inability to exclude specific files from the scm poll would be a deal breaker. Did you also ask this question on the Hudson mailing list?
users <at> hudson <dot> dev <dot> java <dot> net
The only workaround I can see from reading through the docs seems to be triggering builds based on p4 triggers, where you could then programmatically do whatever you want, but that doesn't seem to be a very simple approach.
I don't believe there is any way to configure Hudson to omit part of a Perforce workspace when polling. You may have better luck by setting up two different workspaces - one for build test using a default POM and one for your releases with the auto-updated release POM. The two workspaces could differ on just this one file and modifying the release POM would not trigger a new build.
Check out how to do individual file mapping in a workspace in the P4Guide.
Its possible to update the description of a changelist after it has been submitted, so if you build to a certain changelist number you can then update the description of that changelist to include your build number. This shouldnt trigger a new build.
What is "POM"?
You can have Hudson "Create or Update Label in Perforce" (see near the bottom of your project's configuration.) You could use that along with the BUILD_NUMBER environment variable that Hudson provides, giving you unique build numbers and stamped P4 labels of said build.
I have all tagging, ChangeLog updates, and packaging done by our checked in build code. This allows us to:
Create RC and appropriate tags without starting anther build
Allows us to debug all aspects of our build on any dev machine, not just those with Hudson.
Allows us to exactly recreate how a package, tag, etc was done in at any point in the past.
I had a similar problem checking in compiled src. I was able to find an alternative but i did consider the following.
In hudson specify a child folder of your project to poll. I.e. don't actually have hudson check out your project, just an incidental folder.
Add a shell script to check out your project proper.
Run you normal scripts.
check in your pom. The trick here is that the folder being polled won[t have changed at this point.
Not ideal, but works.
The perforce plugin has had polling masks for a while now. It's in the Advanced section under "View Mask".
Basically, you list a subset of files that you want polling to check for changes. Unfortunately there's no easy way to exclude files, so you'll have to create a list of file specs that specify everything BUT the file you want to exclude. So if the version is contained in a pom.xml, I would need to specify the files and directories that don't contain it.
For example, if your directory structure looked like this:
./pom.xml
./lib/
./src/
You would specify,
//depot/project/lib/...
//depot/project/src/...
as the view mask, and check the checkbox to use it only for polling. There are a few limitations with this feature, such as not being able to use '-' to exclude file specs, but it's still a workable solution for now.