Initially we didn’t use any source control software. Now we are using TFS 2010 for version control. Currently we are facing issue related to how to handle changes with production code and code that is under development.
Assuming we have published a version 1.0 to the web using visual studio 2010 publish with source code x. Now we continue to work on the source code to implement more features. Noow the source code has changed to x.something.
During that time we receive bugs reported by users. Now how to handle such situations since bugs has to be fixed in source code version x. And we don’t want to use x.something version since it has few unfinished features which we don’t want to publish on production.
At this time what is the recommended practice.
Are there two repositories for different versions of source code? If yes then how to fix errors when then come –first update current version or the published code, since we don’t want those errors to exist in current development version.
look into Branching - you can find a good guid here:
TFS Branching Guidance
I think you need/want something like the Branch per Release of Code-Promotion Branches described [here]: or
2
I like those too, but they are more comples (too complex?):
(taken from here - only in german sorry)
You should put a label on your code when releasing in prod, and then making a branch immediatly.
TFS2010 doesn't support "branching by label" though the UI anymore. See "Branching by Label in TFS 2010".
If you didn't make a branch dedicated for fixing the bugs in prod right away, you still can use the command line for branching by label. See "Branch commands"
Create a branch for your released version (x) if you haven't already. Fix the bugs in the release branch. Merge the fixes into the development branch (if applicable). http://tfsbranchingguideiii.codeplex.com/ has recommendations on branching and merging.
Related
I have some xamarin.forms 1.xx( I dont know which version) project on multiple platforms Android and iOS. And I've been asked to upgrade it to the maximum available right now version of xamarin.forms.
Therefore, I have 2 questions:
1) How to determine which version of forms I'm using right now (I'm working in Windows environment using Visual Studio 2015 ).
2) How to migrate/update to newest version of forms? (step by step, if it's possible). I have no idea how the result of that kind of operation supposed to look like, cuz I have never done anything like this before in my life. And what the best practices are?
What I've done is opened VS2015->Help->Xamarin release notes, however there was nothing about version of Forms I'm using. Also, I went to the official xamarin website and there was no guide how to do that. I also tried to look at the release notes the last Forms update and trying to find and fix differences, but my project is so big and I thought that this way doesn't seems right.
I'll answer first the What are the best practice regarding upgrading a Xamarin.Forms application? first and then address your other concerns.
I recently upgraded from 1.5.1 to 2.3.2, and from my experience, this is the steps to go through:
Decide which version you will upgrade from and to.
Read the change logs for all stabled releases between these two versions and look for breaking changes/bugfixes. You can find the release notes on Xamarin's website or on NuGet's website too.
Check regularly for new releases on the Xamarin.Forms forum and check if any reported issues may affect you. Every time Xamarin makes a release, there is a thread full of comments from other developers that may have encountered issues you might be interested in.
Using your favorite versioning software, make sure that all local changes are commited or stashed and create a new branch for your Xamarin.Forms upgrade (you don't know how long the upgrade will take and you still want to be able to send patches during the process)
Upgrade: Read the Important notes at Xamarin.Forms 2.3.2 release notes, especially the When upgrading Xamarin.Forms take care not to simply "update all" as ... part. Remember to upgrade on your PCL project, on your iOS project and on your Android project.
Test your whole app on as many devices as possible and for the longest possible period before you merge your branch back into your development/master/Main branch and address the potential incompatibility issues that may have been created in your development/master/Main simultaneously.
Step 3 is very important as it will allow you to reset back to your starting point and restart if you should fail to upgrade for whatever reason.
Xamarin.Forms is moving fast so it's important that you always keep an eye on what's going on even if you don't upgrade.
Which version am I using right now?
You can check that in the NuGet package interface or in the packages.json file in your project.
Let's say you have a bunch of code and let's assume that you have a first working version. This is version 1.0. You go to your git repository and tag the version. Then in that exact moment you have your first tag or release. Then you have in your code version number 1.0 and in your repository tag number 1.0.
My question is, when exactly do you change the version number in the code to version 1.1 (let's assume we don't care about 1.0.1):
A) do you change it right away after the tag 1.0 is done? Therefore all your code from this moment on belongs to version 1.1. This version "ends" when you create a new tag 1.1, which is the stable version 1.1 and change to version 1.2 in the code.
B) do you change it after you have done several code changes and publish your second tag (tag 1.1)? In that case you have a tag version 1.0 of the stable code and you are making improvements in the code. All new changes you do belong to version 1.0. Then when you are finished making changes, you change the code number to 1.1 and the tag number to 1.1
Nerdy question right ;-)
This is somewhat subjective but I would strongly suggest A. Branch out at a the time of release and start working in a new branch.
It's because your users are then in sync with where you left off in v1. If you introduce a number of features for the working v1.1 branch and possibly some design changes which kind of strongly branch away from v1, you can always come back to what the users are seeing by updating to the v1 branch.
Branching in this way based on release is useful as "checkpoints" based on what the users actually have, not based on what you intend to deliver. This way when a user reports something, you can easily know which version of the code they're actually using and quickly flick to it.
This also leaves some breathing room to do easy "service patches", like a v1.01. I know you wrote that you don't care about that, but if your users report an issue in v1 that you've already kind of solved in v1.1 or the v1.1 design has changed in a way to make it no longer valid, but you want to sneak some patch in between there, you can update to your v1 branch, make a minor tweak, and release a v1.01 service patch kind of thing. There's a bit more wiggle room there for that kind of thing.
As a hypothetical, imagine a user reports a glitch in v1. You can't reproduce it in your latest development branch. Now does the fact that you can't reproduce it in your current changeset mean it's fixed, or that you simply can't reproduce it? The easiest way to know for sure is to be able to quickly switch and use the same version you released to the user. That's where branching off and kind of freezing the branch at the time of release is useful.
Of course you could do that without branching or tagging at all if you just comment your changesets in a way such that you know which one is which. But then there's little point to tagging/branching in the context of a release. If you do it as an organizational means and a way of isolating changesets to one place, I'd suggest doing it in a way that keeps those branches in sync with what the users actually have.
I'm working on a project and I'm using TFS as a source control, i was thinking of using TFS branching,
as now i reached the current situation:
I have released a beta version of the project.
I want to have
a team who do refactoring on the design and code.
I wanna have a
different team who would add fixes and resolving small issues and
maybe add tiny features to the beta version.
I think the refactoring is going to make a lot of changes to the project, probably adding new class projects, and making big changes to code, so i`m kinda thinking merging would be a big issue.
I don't know which scenario i should use, i read some about branching Here, and I`m kinda hesitate to use it, what do you guys think ? what would you use for this scenario ?
I dont think merging would be any issue. You can find some branches examples here
Is there a way to make visual studio not care about dll versions? Is this a bad idea?
I am resetting up my dev machine and I just installed the latest version of Pex and Moles (version .92). All my projects are on version .91.
We are in the middle of a release and don't want to upgrade right now. Also, I cannot find an installer to version .91.
When I try to compile I get a message that I am missing the reference. (Hence this question)
The version is important.. By definition, there is a difference from each released version to the next (or there would be no need for a new version). Your program may not perform correctly if you are expecting one version and instead have another.
This was a part of what was known as "DLL Hell" in the pre-.NET days... If you needed to use a third party component (Crystal Reports Viewer is one we always had to deal with), you would just use the reference to whatever installed version was on the user's PC. Our retail locations had to have a specific version of Crystal Reports for their bookwork reports to print correctly, and because of that, we had to hold on to an old version forever.. Upgrading Crystal on the PC broke the vendor's bookwork app. On my first ever PC, I had several applications break when I would install or upgrade another. In particular, Real Player broke my telephone answering machine software. Goofy stuff like that...
So, the version IS important, even if it is an annoyance. It's also why I have a bias against third party tools that I have no code for, and can't recompile myself.
If you look at the properties of a referenced DLL, you will see a property "Specific Version". If you set it false, it doesn't track the specific version in the project file.
For this to work, you have to somehow fix the references where ever they are used. You can do this by opening every solution and fixing the references (at which time you could also just update the references to the correct version, paying heed to David's comments).
If you have a lot of solutions, you might use a tool like sed (see this post for windows versions of tool like this Is there any sed like utility for cmd.exe) to just update the project files as needed all at once.
Is there a decent Subversion client available for XCode? I am so tempted to write my own as of this morning after having a conflict on an update. I've done merges manually editing the ">>> mine" and "<<< theirs" markers but there has GOT to be a better way in this day and age. Does anyone know of an easy way to resolve conflicts graphically? It seems like SCM conflicts and svn history queries are my two most missed features in all of the Mac SVN clients I've seen so far. I use Versions and sometimes the built in XCode SCM support. I've also looked briefly at Cornerstones web site. (Is Cornerstone any better?) Does anyone have any ideas?
I'd suggest using git-svn with GitX for most things. The GitX commit interface is so nice it's really hard to go back to anything else.
For conflicts I use Emacs, which offers really nice, fully editable, color-coded 3-way merge.
You also might check out the WWDC 2010 videos/slides (free at Apple's site if you're a registered developer) regarding SCM support in the upcoming version of Xcode.
As a GUI, SmartSVN offers a basic conflict editor (though I find the the application very slow to refresh on a large source tree). Often I find myself going back to Emacs which has support for subversion via Psvn.el, and that has a very capable 3 way diff with ancestor revisions, custom region skipping and other goodies.