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.
Related
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'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.
In my program I am calling methods that do lots of changes to a content of a folder, including:
deleting files/folders,
changing files/folders,
adding files/folders,
adding/deleting symboliclinks/junctions.
That is no problem so far. But I came up with the idea of optionally projecting the final state of the folder (after all the operations are done) to another folder, so that the original folder remains untouched.
Just copying the folder before applying the operations is not appropriate, because the operations might delete large chunks of data, that would have to be unnecessarily copied beforehand. And so it came to my mind, that a professional programmer would certainly not approach it this way.
Ideally I would write something like this (pseudo code):
originalFolder.Delete(lots of files).Add(Some other stuff, maybe change some permissions etc).ProjectTo(newFolder)
Is there some kind of design pattern or other way I could achieve something like this? Maybe some virtual file system I can do stuff on before materializing it into a seperate folder?
I know how to write extension methods and I have already written lots of trivial ones, but I really need to be put on the right path on how to achieve something like this.
If the adding and deleting would be done through YOUR apis, then you can modify the list of files in memory without touching the physical files and when you are set do the changes with the copy on the final folder.
Of course that assumes that you don't need the files changed in any matter thus you won't need to read the new structure through the filesystem before committing, I mean that it would be totally within your application.
If this was on linux, I would have suggested another solution which is to use hard links and hard link the files to many folders and thus actually do whatever you want with the first folder without touching the second. I am not sure if NTFS supports that.
If all you want is to delay changes to the original folder until you are certain that you want to commit them, then a Unit of Work pattern might do the trick. Store all operations that are to be applied to the folder in a container, and then commit them sequentially.
This sounds a bit dangerous though, since changes to the original folder before changes are committed easily can mess things up. In that case you would have to implement some sort of concurrency check to be as certain as possible that all operations will succeed.
In the near future, I will be adding some features to my WP7 app. As seen here, I will be making some changes to the database. Where and how would you handle updates like this in the code? I don't think there is a way to add code anywhere than runs on an 'update'. It's hardwired into the apps code.
I'm thinking of having a flag that gets set in IsolatedStorage. Name it something like v1.2UpgradeFlag, and set it to false. In the App.xaml.cs, check that flag, and if it is false, meaning the upgrade hasn't run, run some set of code, and update the flag.
The idea of having code sitting there like that, that may not be applicable to multiple versions ago kind of clunky.
Edit: I'm also curious how I would manage cumulative updates to the application. So in v1.2, I have some code that updates the database schema. What if someone buys the app while it is at v1.3? I don't want them 'getting' v1.1, having the app run 1.2 upgrade code, to get to v1.3.
Since this is the first time you will have to run a database upgrade, I would be tempted to add an extra table to the schema that will hold the version information. If, when you attempt to retrieve the data, it gives a NotFound error, you know you will need to run the upgrade. That way, you can manage the process in subsequent versions without having to manage the extra file.
In order to do cumulative updates, you can use the same mechanism. You can maintain a method that will update the database from v1 to v1.2, another method to go from 1.2 to 1.3, etc. The method that maintains the upgrade process may look something like this pseudocode...
var currentDbVersion = GetDbVersion();
while(currentDbVersion < currentCodeVersion)
{
switch(currentDbVersion)
{
case 1.2:
RunUpgradeFrom12to13();
break;
case 1.3:
RunUpgradeFrom12to13();
break;
default:
break;
}
currentDbVersion = GetDbVersion();
}
That should allow you to upgrade from any previous version to the current without maintaining several code paths (since a 1.0 to 1.2 upgrade will never change, and you should have a known start position for each cumulative step)
There may well be far more sensible ideas out there, but this is the first thing I thought of.
I want to set expire date for my C# Windows application.
It means that i.e after 30 days my app won't work. It is easy to do when we use system time, it means whenever my program starts i check today date and expire date.
The problem is if the user changes system time, my comparison won't be correct.
What other ways can this be done?
I would figure out a better way to get people to want to pay for the application, because fighting it can be a very futile effort, although you can make it more difficult with things like hardware dongles, phone home services, etc. If your price point is not high, customers won't want to put up with this.
May be keep a dummy .dll file in your app install folder, open it and keep the number of days and install date time. Every time application loads up, check it. .Dll files folks wont try to open and read. May be you can encrypt and store in it too. This could be very simple.
The first line of defense is to check with a server, checking out their system time so that the user cannot change his own. Also try to hide the start date (under some dummy name in the registry perhaps). These are pretty futile things though, smart users will be able to 'crack' this with minimal effort.
It's trivial to disassemble a C# application, so whatever you implement will be liable to easy circumvention. The best choice, in my opinion is to use third-party Licensing tools but do bear in mind that all can be circumvented, although they will be more robust.
How likely is your app to be pirated and is it worth the time/expense to do anything more than cursory checks?
It might be easier to simply have two versions of a DLL - one that must communicate with a server every X days to make sure it's still active and the "unlocked" (purchased) version.
As has been noted, determined users will find a way around whatever you do so you have to evaluate effort/return to determine how much attempting to secure your app is worth.
You could use a website that keeps the time to determine how long the program was installed.
You are probably going to get advice saying that it is not woth your effort.