Does anyone know how to configure the auto-generated message that is created on a git-tf checkin command to TFS?
I would like to have more control over that to allow for adding a comment during checkin.
The agile process system that my company uses allows adding a task number in front of a comment, and then will associate the source code with the task in the agile system.
Anyone have any ideas? Anyone have any customized git-tf source?
As mention in this thread, you can try!
I've upgraded to the latest version of git-tf and noticed that it generates a different comment for a tfs changeset after doing a checkin than the previous version (I'm using the --deep option, no message provided with the command).
Is there a way to revert to the 'clean' (without the commit guid, author, commiter) comment from git?
Yes, You can use the --no-metadata flag when checking in and it will revert back to the "clean" comment.
So you don't have much control on the comment, but at least you can reuse git comments.
There is a request for making that option the default.
Related
So I have a TFVC setup that has no Git branches however when I go to link a work item, it only comes up with Git, how do I link work items to TFVC branches? The only documentation I find all uses Git, for everything.
I am trying to have my tasks set up so that when a new task is created, I would create a branch off of Development for that task. However I can't seem to do this as everything is defaulting to Git and it seems like my workspace has no knowledge of the TFVC branches!
Link work item to Branch only support for GIT, it's not supported for TFVC. See Link types showing in the Development section for details.
For Team Foundation version control (TFVC), it lets you link work items to version control changesets or versioned source code files by using the Changeset and Versioned Item link types. When you check in pending changes or use My Work to check in changes, work items are automatically linked to your changes.
So, you can link work item with the link type Changeset or Versioned Item, or create another Git repository, you can use both TFVC and Git in the same project.
UPDATE:
That's a good idea to support TFVC, I have help you submitted the user voice here, you can go and vote it up to achieve it in future.
Is there a way in TFS to edit files and then (maybe) merge them later without having to do a checkout? Basically edit then only touch source control when I decide to update to the server, not in advance.
Or has 5 years of Mercurial and Git just led to me getting confused about how TFS works and what I want is not possible and doesn't matter because "checkout" is not exclusive. (most likely option? :-) )
(I have been here but that does not solve my issue)
There are ways to cheat that, but there's no good reason to do so. When you check out code from TFS, you're getting a local copy to work with. When you check it back in, it creates a changeset, which is an atomic commit of your changes to the source code repository. If you don't want to check it in, and go off and do something else, you can create a shelveset, which can be named and unshelved whenever you're ready.
Similarly, if you use Gated check-ins, that process creates a shelveset automatically and sends that for a validation build. If it fails, you just make changes to your shelveset and try again. If it succeeds, it checks a changeset into the source repository. It helps prevent checking in breaking changes.
So in Git you can squash multiple commits into a single commit. So for example, let's say I checked in a change, but I realized I forgot something small, so I make the change locally and then I commit again. With Git squash you can merge those into one commit.
My question is does TFS have any sort of method for doing the same thing?
No. TFVC uses a totally different version control paradigm than Git; it does not support history rewriting actions like squashing and amending.
No, its not supported. You can't change the history of every changest in TFVC. If it can be achieved , it's a violation of the principle of source control.
And also you can't create a new changest then merge with the old changest, There have been a featured request in Uservoice and be declined by PM of TFS.
TFS to merge multiple, non-continuous changesets.
Thanks for the feedback on this idea. We have reviewed this feedback
and determined that we will not be able to complete this suggestion in
the foreseeable future.
Matt Mitrik TFS Program Manager
My build system (Team Foundation Server 2015) does the following:
Get latest
Un-shelve developer changes
Check-out version file
Modify version file
Check-in modified version file
Run build/unit test
Check-in developer changes (on successful build/test run)
My issue with this method is that the build agent is modifying a file and checking that change in. To me this feels dirty.
So is there a better way of doing this, is this really best practice?
In my opinion, it's better to put version information in a version control system, not in a file. I haven't worked with TFS, but in my work I use Git and put version information in git tags. Using the git describe command you can get the information about the latest tag, a number of commits since the last tag and hash of the last commit. It also can provide you with information about uncommitted changes in your working copy.
All this information gives you the ability to distinguish one version of a binary from another.
And you don't have to create meaningless commits inside your repository.
I have installed Jira and the subversion plugin (with success from what i can tell from the administration panel - subv. plugin installed).
I then add a repository that I have created on the file system, BUT i cannot see an option which will link/connect a new or existing project to a SVN repository. What i want to do is link a project with a repository so I can track commits made to the project (link commits with issues). After some searching i found that this is possible but I cannot figure a way to do it.
Do I need another plugin for that? I have tried googling for the last hours but I cannot find anything related.
regards,
The way SVN-Jira linking works by default is to simply put the issue identifier of the Jira issue in the comment when committing to the SVN repository.
It can be helpful to enable comment editing in the repository, if you have past commits or users who forget to add comments when committing.
Example commit comment:
Fixed problem with login. See issue MYJIRAPROJECT-26 in issue tracker.
There's a service in Jira which scans the SVN repository at regular intervals, and builds a cache of any SVN revisions where an issue identifier appears. Depending on the polling interval, it make take a few minutes for the commit to show up in Jira.
The polling time is controlled by the JIRA Service for the SVN plugin. See Admin, Services.
~Matt
you can enforce that future subversion commits require a jira issue reference for more reliable--than relying on your programmer's word ;)--jira-subversion integration
the jira commit acceptance plugin can be configured to block commits that don't include a valid (defined by subversion-jira project mapping and/or regular expression as appropriate to your situation) jira issue reference in the commit comment
reliable jira-subversion linkage availability allows handy stuff like:
Integration with issue trackers