I need to add a feature in my .NET app that allows users to understand which changes they made to configuration files. Every configuration is archived in folder. Eg.
ConfigV001
ConfigV002
...
ConfigV100
I think I could use git diff as follow:
git diff ConfigV001 ConfigV001
to get differences but then how can I format the output to obtain something like this? (the screenshot it taken from github-for-windows)
I would have the list of changes between the 2 versions (added, updated, removed files) and the changes for each file
Take a look at Diff.NET; includes source code for the utility and screenshots showing comparable behavior to what you're looking for.
Related
I'm developing C# on Visual Studio. I was able to config TortouseSVN to use $Rev$ property inside the main .cs file. As I tested, every time this .cs file is changed, latest revision number is updated on this file.
But then new tests showed that if any other file is changed and commited, this .cs file doesn't have latest revision number.
I'm thinking then on using Visual Studio's standard \Properties\AssemblyInfo.cs file to store SVN's $Rev$ property, and use .Net assembly to read it as I already do with FileVersion. This also has the advantage of storing version/revision metadata separated from normal source code.
But then, is there a way to setup Subversion/TortoiseSVN to always update $Rev$ property on a given file it is present, even when this file hasn't changed?
Update. What I'm looking to achieve is to automatically store the last revision the SVN folder was commited. This number will then be part of compiled binary (which will be generated after commit) and be shown in logs together with the app version, and be used on DEV, TQS and PRD environments. This way I'll keep in each log what revision a given execution refered to and be able to see what had changed since that execution and current HEAD.
Of course this is an app-wide info and not a specific info per source file. But I think SVN won't support updating a specific file every time a commit happens.
My best idea, a very very ugly one, would be to create a static class and during startup make each object, as they are instantiated, call it and inform their revision. This class method would then store the max value, which would then be app's compiled revision.
I basically have what's a poor-man's versioning...
At one point someone copied / renamed the 'file.cs' to 'old-file.cs' - and all its history up to that point going with it.
And then created a new 'file.cs' - with all the new history going forward.
I ended up with the same file having history split up in between these two files.
I know this must be simple (if possible),
- I've tried searching, but my problem is how to 'phrase the question'
- This isn't a 'merge' (I think - I don't have branches involved),
- It's not the typical 'move' either
- I've looked up the tf command line but nothing resembles what I need
- I have the TFS Source Control Explorer Extension installed (but it can't really help with this)
FWIW, I'm using the VS 2015, C# project (both files are part of the same project), though I don't mind if the solution is command line 'tf' or whatever gets the job done.
So if anyone could help point me to the right direction at least it would be much appreciated. Thanks!
I have tested with TFS 2015.3 + VS 2015.3, but couldn't reproduce your scenario. In my test, the history in old file has been migrated to new file. You may check my steps to see whether they are the same as yours:
Rename a file gulpfile.js to old-gulpfile.js, and check it in in Source Control Explorer. Then copy old-gulpfile.js in workspace and modify it to gulpfile.js, and add it to source control and check it in.
Check old-gulpfile.js history:
Check gulpfile.js history:
You can see all history in old-gulpfile.js is also in new gulpfile.js file.
I'm trying to get one of our internal c# click once applications into VSOnline for source control to allow access for an external developer.
I think I've got it set up and working in the Source Control Editor, but am having trouble working through how to actually use the setup day to day.
I've got some git experience but zero TFS experience, but went with the TFS option as I thought it's more likely developers are familiar with it than git.
What I'm trying to achieve is 3 branches; Main/Trunk, Dev and Release and be able to deploy at least Release and Main. Release is for external clients, Main for internal clients.
At the moment my Source Control Explorer looks like;
DefaultCollection
-->Name of project
---->(Branch icon) Dev (created as a Branch from Main)
---->(Branch icon) Main
---->(Branch icon) Release (created as a Branch from Main)
2 things;
In terms of use I'm not really sure how to swap between the branches for coding / making changes? Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way? I'm worried about someone committing the wrong file and causing a mandatory uninstall/reinstall of the app.
Any pointers / docco greatly appreciated; just note I'm using VS2010.
Thanks,
Liam
How do I swap between branches
If you're used to GIT than the 'heavy weight' branching in TFVC can be a bit confusing. There is no real "Switching between branches" as you've encountered. You map a branch to a local folder and by opening the files there you're "working on that branch".
As Lee points out you can create separate workspaces for each branch, which will isolate the work areas for each. If you're using a Local Workspace, each workspace gets its own "/tf$" folder, the TFVC equivalent of the "/.git" folder.
There's a couple of documents on MSDN that explain this in a little more detail:
Set up TFVC
Create one or more workspaces
Optimize your workspaces
How do I check in
A changeset in TFVC is the equivalent of a commit in Git, it's a logical set of changed files that is committed/pushed as a whole, or not at all. But just as in Git, you can commit all the changes to your local work area at once, or you can exclude certain changes from the first commit and stick those in a second.
In TFVC you'd normally try to commit a logical set of files that fixed the bug, achieved some goal etc. Though it's still possible to check-out/check-in files individually, chances are much higher that you'll actually cause the sources in the main repository to be in an inconsistent state that way.
See
What is a Changeset
Check in your work
Shelving your work
As for your second question
Depending on how far you'd want to go, you could setup Team Build to actually build the application and to take the configuration from a specific location during the build process. That way you wouldn't have to store the configuration for your production environment with the development settings. Configuration files can contain sensitive information, you might not want to have them in Source Control, except for the development versions.
You can also store the config files in a special folder in each branch and make sure that each time you merge them, they're updated accordingly.
And you can, as Lee mentions, look into Config Transaformations. which apply some XSLT to your config file in the build process. That way you can have multiple config files stored in each branch and the selection of your "Configuration" in Visual Studio will define what the final config looks like.
See:
Tricks with app.config files and click once
The _PublishedApplication Nuget package
SlowCheetah
In terms of use I'm not really sure how to swap between the branches for coding / making changes?
I recommend creating separate workspaces for each branch. This way you won't accidentally check in release code when you are trying to check in dev code. Also, when you want to switch which branch of code you are working on, you switch your workspace. This should keep things "cleaner" and easier to work with.
Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
You shouldn't have to manually check it out. If I remember correctly, it will default to auto check out when you start to make changes. You can check code in however big of chunks as you want. But make sure if you are checking in changes to ClassA.cs that reference needed changes in ClassB.cs, you check that in as well. You don't want to leave the source code in a broken state for the other developers.
If you start working on something and have to suspend that work to do some other task that rose in importance, shelve your work instead of letting your workspace get cluttered up with half done work that makes it difficult to manage check ins.
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way?
I'd look into using web.config transformations for this. You'll still want multiple branches but to separate tested/completed/developing code from each other.
I'm hacking around git repository at low-level, trying to retrieve file's history from it. And having difficulties identifying file modified and renamed in a same revision.
I'm developing C# application and I need to implement git log --follow FILENAME feature.
Modification is simple: search for file with given path in trees attached to revision, if SHA1 differs — Voilà!
Rename is simple too: if search by given path was not successful — look for object with same SHA1, as previously, if found — Voilà!
But if not found it might be either file deletion and my search is over, or rename and modify in same revision... but how to distinguish between these cases?
I've studied everything I found regarding Git internals, but still cannot find out what to do in this case, what might be common between tree objects corresponding to the same modified and renamed file in different revisions?
Many thanks in advance for your help!
Git allready has that functionality. See -M/--find-renames, -C/--find-copies and -C -C/--find-copies-harder options to diff (applies to log and show as well) and --follow option to log.
The principle of --find-renames is, that if it sees new file in a revision, it looks at the files removed in that revision, compares them and if any is similar enough, declares it a rename.
Edit: In more details: To detect copies/renames, git compares the two revision first it compares the lists of files. Than for each path that only appears in the new revision it compares the content with content of files from old revision that -M—were deleted, -C—were modified or -C—all and if they are similar enough (which requires diff), marks it as rename or copy as appropriate. This is part of the diff core and is available to all commands that show diffs in any form, including the name-status, which does not do detailed line-by-line analysis. On top of this the --follow works by iterating the revisions one by one, does a name-status diff with rename detection and outputs the revision if the file was modified and remembers the new (old) name when it was renamed.
I have a program that requires a few large (~4 or 5mb) files. Once a week, every week, there are new versions of these files with minor changes. Mostly just a few lines added or removed.
When the program starts, if there's an Internet connection, I'd like the program to update these files automatically. Instead of downloading the entire new versions of the files, I'll like to download just a patch based on the client's version of the files that updates them.
How might I do this?
I have total control over the server.
That is a tough problem to solve if you don't have any for knowledge of what is in the file or the server doest have a facility to allow you to request differences. Any program you write that does not have a way to determine the differences with out looking at the old and new file will have to download it anyway.
C# doesn't have any built-in facility to do this, but it sounds like your requirements aren't complicated. Look at how diff and ed on Unix can be used to patch a text file based on an easy-to-grok delta. Of course you should check the resulting file against a hash and fall back to a full download if it isn't correct.