I'm new to TFS, we have just started to use TFS to manage our T-SQL code.
I would like to know if it's possible to create a pre-parse script to be run automatically when checking in scripts, to also make additional changes to the file? Exchange tabs to spaces within the file for example.
I would also like to be able to insert the changeset id as a comment in the script that I'm checking in.
So is it possible to know the new changeset id in pre-state while checking in the file?
This script I would prefer to develop in C#
The feature that you're after is called "Keyword Expansion", it is not currently built-in to TFS.
For more history and discussion on the lack of Keyword Expansion in TFS, see this blog post from Buck Hodges.
There are two ways to achieve what you're after:
Use a client-side TFS Check-in Policy. This is code that executes on your machine before the change is submitted to the server. Here's an example.
Setup a Build server and a build script and enable 'Gated Checkins'. Then as part of the build script, make the additional changes to the file, before checking in.
There are a number of downsides with both of these approaches though:
You can't predict or know the Changeset ID, until after it's actually been checked-in. So you would either have to leave this out, and settle with something like current date/time. Or you would have to get funky and check it in again, with the previous changeset number.
With client-side TFS Check-in Policies, they have to be deployed to every user who wants to check-in. That is usually too much of an administrative burden, so people don't really use them.
Related
I started merging 2 branches, resolved all conflicts, now i have a lot of files to check-in. I started to look through all these files and the 1st file shows me this when i click compare to latest version:
I see that there is no changes were made but this file wants to check-in, what to do? I think I need to exclude this file from checking-in (with operation "undo") to keep commit clear. Am I right? Is it normal for operation "merge"? Or I have to commit everything? And why this file is in "check-in" section?
Just undo the change.
There is clearly no functional issue, just a formatting/encoding issue between your codebase and the one you are merging from. Often I see similar when different users select different line ending preferences in their local git configuration. There may be other options that could result in similar behaviour.
See the GitHub article on line endings
I'm using Azure Roles and Cloud Services.
So my config is no longer going to live in web./app.config, it will be in ServiceConfiguration.Cloud.cscfg and its .Local. sibling.
Each dev on the team has (optionally) their own DB for local dev (so that EF doesn't get upset) so we're all going to have different settings for local Development.
But we don't really want to have to maintain a personal commit changing the connectionstrings to our local ones, if we can help it.
In the olden days, I would have achieved this as per advice like this: http://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure or this: http://www.codeproject.com/Articles/602146/Keeping-Sensitive-Config-Settings-Secret-with-Azur
Which allow some of the settings to be indirectly defined in another file, which we could then git ignore.
But all of those examples are referring to appSettings or similar - which doesn't exactly appear in the .cscfg
I'm about to try just applying the same sorts of things, but I thought I'd ask here before I start so that:
if I fail then maybe someone have answered when I come back
I'm more likely to come back and report the answer if/when I do solve it.
All thoughts and advice are most welcome even if they don't directly solve the question.
This problem isn't specific to Azure. How does one maintain a default config file, while allowing individuals to use customised versions of it that play nicely with source control...
I think you're right to look for a way to do it in the framework first, but failing that I'd go for something along the lines of the answers here:
git: can i commit a file and ignore the content changes?
In our case, that would entail either:
Committing the config file, then ignoring it.
Committing a "template" version, that users base their own copy on, and pre-emptively ignoring the version they'll create.
Bit of a general answer, but hope it helps!
C# isn't enough for me, so I've taken advantage of the newly-open sourced Roslyn to extend it, say by modifying it to use French quotes.
But I don't want to build my newly-French-quoted files on the command line! I want Intellisense! I want a nice UI! In short, I want to get Visual Studio to use my Roslyn, not Microsoft's.
Can I do this yet? If so, how?
Quoted straight from this link in your question:
ADVANCED USAGE
It is also possible to update your copy of Visual Studio to use your
own built version of Roslyn (for example, to see how the IDE reacts to
your changes), but it’s slightly complicated:
First of all, you’ll need to use the release fork, not the master
fork. This is because the compiler code is constantly changing in
reaction to feedback, and that includes changes to the APIs that are
used by the non-open IDE bits in the Roslyn preview in order to access
compiler information (until the APIs get locked down as we get closer
to completion). When these APIs change, the ability to communicate
between the two is lost. The release fork, however, accurately
reflects the state of the code at the time that the Roslyn preview was
snapped, and so is safe to use as a baseline for this sort of thing.
(You can see the fork on the Roslyn CodePlex site by choosing “Source
Code” and then opening the “Browsing changes in” dropdown – it’s
called “releases\build-preview.”)
To switch to this fork in Git, you will need to execute the following
two commands from an appropriate Git prompt in your enlistment:
Git fetch
Git checkout – track origin/releases/build-preview
Your git repository will now have the contents of the
releases/build-preview branch. Once you’ve done this, you can switch
back and forth between the branches using Git checkout master and git
checkout releases/build-preview. (Details on Git usage are beyond the
scope of this blog; see
http://www.git-scm.com/book/en/Git-Branching-Remote-Branches for more
information on branching in Git.)
Second, you’ll need to disable Visual Studio’s strong-name assembly
checking for the relevant assemblies first. There’s a script to help
with that, which you can find checked into the source code at
Src/Tools/Microsoft.CodeAnalysis.Toolset.Open/Scripts/Prepare.bat.
With all of that done, make your changes. Then, after building, ensure
that CompilerPackage is set as the startup project, and then
F5/Ctrl+F5 to launch a VS instance containing the changes.
Please note that we will never accept pull requests for the release
fork – we need to keep it pristine and accurately reflecting the state
of the code relative to the Roslyn preview bits. Anything you actually
want considered for submission would need to be ported to a fork
created from the master first.
Interesting times ahead. Though I have a certain amount of trepidation about finding myself in a company where they use an entirely customised compiler to do awful, awful things. The gun to shoot yourself in the foot with has just been upgraded...
I need to make some test changes on app. The app has version control (by Perforce). How to make a branch (from Perforce) that I don't intend on check back in so that I can do some test modification.
It depends on what you mean by not intending to check it back in. Do you mean never, or just not into the main branch?
If you really just want to make some local changes, and then throw them away, without needed any form of version control on the changes themselves, then you don't need to branch at all. Just sync up, check out what you're changing, and then revert the files afterwards. You can even re-sync the files while you're working (resolving conflicts) if you want to check your local changes in the later build. Just don't submit anything, and you're good (just remember that P4 has no backup of your local changes, so if your PC dies and you didn't back it up, tough).
If you want to be able to switch between your local changes and your normal build, you could 'shelve' your changes, which essentially submits them into P4, but keeps them in a changelist rather than having them actually integrated into the main branch. That way you can revert back to the "real" version of the files, and re-sync your own changes again later - possibly even on a different machine. This is a lightweight way of being able to make local changes, while still having a copy on the P4 server without polluting the depot.
If however you want a proper change-tracked branch of your own, you could integrate the version you want to base it on over into a fresh part of the depot, and then use a client-spec which syncs with that while working on it. You are free to integrate between your branches in either direction, whenever you want. You can branch either the whole tree, or just a sub-set of it, using client-specs to sort out which bits go where.
Alternatively the recent versions of P4 have "streams", which are an alterative way of handling your depot, more suited to running multiple development and release branches in parallel. It's probably not what you're looking for.
In terms of exactly how to do these things, I recommend checking out P4's website, which has pretty good documentation and lots of tutorials.
Actually you do not need to create new branch for test your change. Just make a client containing your app and sync your local computer. After that you need to change on specific files or add new or delete by shelve. Then just build your app with shelve. If you find your change at build artifact and if you think that your change is correct then you can submit it to perforce.
The easiest thing is to go to the "steams" tab. Create a new stream and check the check box for branch from where you want to branch from. Super easy.
I want to modify in certain way(Actually format the files in a code formatter) before they are committed to repository.
I have found out from Precommit example (Use guest as name and no password) how to write in python.But what i want to know is how to get list of files to be committed and other command line arguments this one takes.One more thing i prefer is to write my own pre commit hook in C# rather than Python or any other script.
Few points
I will write a exe which will format,but i want the list of files being committed
How to configure this with svn.
Precommit hooks that modify the committed files are considered 'a bad thing':
http://svnbook.red-bean.com/en/1.5/svn.reposadmin.create.html#svn.reposadmin.create.hooks
The idea merits a big red box in the official SVN documentation, and warns that this will affect how the SVN client works with the repository in bad ways.
The first parameter passed to the pre-commit hook script is a path to a text file. That text file contains all the paths which are to be committed, separated by newlines.
But for your situation, you might better use the start-commit hook: that script is called right before the commit begins, but after the user selected the files/folders to commit. The start-commit script is called after the user clicks OK in the commit dialog, and before the actual commit begins. This hook has a list of exactly what will be committed.
First of all, I think this is a bad idea. Why would you want to change code before a commit? in my opinion it's much better to check for code formatting/standards violations and abort the commit. I would be very frustrated if my code was changed during a commit.
To answer your specific question, use svnlook changed to get the list of changed files. svnlook dirs-changed would give you the directories affected by the pending transaction.
As you maybe already read, a hook in subversion is just a program, called at a specifc time within the commit process with some parameters and a return value. You can place any runable program within the hook directory. So you can also place any .exe there (which can be a .Net program as well). Then check the command line arguments and do whatever you like and return any int value as errorlevel.
Within your application you can maybe use SharpSVN or anything else to get an easy access to the repository to make any checks and send the result to the user.