I am using svn as source control with AnkhSVN 2 for Visual Studio 2010. Very often I am working on one ticket than switching to work on another ticket without completing first one. Is there any quick way to backup updated files for first ticket? This will simplify coding by managing only related changes.
You could
create a patch file for the svn branch you are working on
then revert your changes
work on new ticket and commit
reapply patch
The question I'd be asking is "Does the software build". If it does, check it in to source control. If it doesn't, get it into a state where it does, and check it in to source control.
You don't have to check into the trunk, you can always have a branch that you use for intermediate code which then gets checked into the trunk when you've completed the tickets.
You should use a feature branch for each ticket, and reintegrate each branch into trunk once finished. Just make sure to read the SVN book to understand the best practices when working with feature branches, and particularly to regularly merge from trunk to the feature branch, before finally reintegrate the feature branch into trunk with the --reintegrate option.
You could also create a patch, save it somewhere, revert everything, then start working on ticket2. But it's fragile: you'll forget where your patches are, lose them, or have a hard time applying them because of conflicts caused by the work on the second ticket. And it's also harder to switch from one ticket to another. Feature branches are the most appropriate solution for this, IMHO.
Related
A few months ago a developer pushed and merged a feature branch into our main branch (develop) that contained test files (800MB). I deleted these files from Bitbucket and everything (it was a pain). Now I am looking for a solution that could prevent this from happening in the future.
Is there some kind of process/script that I could run before performing a merge to my main branch? I would like this process to check every single file in the solution and verify that every file is less than 2.00MB.
Not sure if this will help or not, but the solution consists of various C# projects, including unit tests.
Use one of the git hooks to prevent this, either on receiving a push in the central repo, or before merging.
It looks that eventually we moved our project to a bad branching strategy - "Cascading" (in question "TFS -- Sustainability of Cascading Branches" it was recognized viable actually). Now, after reading few articles and seeing it leads to infinite branching tree, I realized that it's bad and want to fix it. But it's not so easy as I expected. TFS allows merges only with parent branches (siblings merge isn't possible).
Here is the diagram of our current branches hierarchy:
Looks weird, but it all started from small changes in latest release branch while trunk has been suspended in the middle of 3-month work. Then we made few internediate releases one based on previous one (up to 1.1.4). But when we started release 1.2.0, the story with trunk repeated and we must have suspend 1.2.0 and implement 1.1.5 hotfix.
Now I faced the need of merging 1.1.5 changes into 1.2.0 branch which isn't possible directly. I can only merge 1.1.5 with 1.1.4 which I wanted to avoid (who knows maybe we'll need to implement 1.1.6 based on 1.1.4 tomorrow). But it seems I have no other way out. Still it will be possible to create 1.1.6 branch from non-latest revision of 1.1.4.
Is it what I must do and isn't there a better way out?
And now comes big troubles and the main question. Eventually I'll need to merge all changes into trunk. And 1.1.5-1.2.0 problem is just a miniature copy of that. That's why I'm asking an optimal and least risky way to perform this merge.
My current plan is the following:
Create branch "1.1.4 final" with the latest stable released version.
Optional: Create similar final branches for all previous numbered releases. Should I do it? Most likely I won't need that versions in the future anymore.
Merge 1.1.5 into 1.1.4
Merge 1.1.4 into 1.2.0. There wasn't much changes in 1.1.5, so I shouldn't run into problems here.
Merge 1.1.4 into 1.1.3, 1.1.2 and downto the release branch. Should I expect conflicts or problems here? I expect and hope not.
Merge release into trunk. Most scary part =)
Stabilize code in trunk.
Now it is time to create a better branching strategy... I'm very unsure about this part at the moment.
Create new "stable" (Main) branch from trunk
Reparent trunk to become child of stable. This solution is suggested in related question "How to fix TFS incorrect branching"
Should I remove current "release" and "R***" branches, or leave them as garbage?
For next comming releases do not create separate branches - instead label the final revisions in stable branch. Actually "stable" branch will consist only of final release checkins.
I'm NOT going to create the "integration" branch for QA of stable features - currently we all live in single active branch without problems.
Create "alternate" branch based on stable for paralel development in case we'll need to once more suspend current work to make some urgent fix. Should I keep single alternate branch forever, or delete it once merged and create a new one (like R125) when again needed?
The idea of this change is to have fixed limited number of branches (ideally 2, at most 3-4).
Please share your thoughts and concerns on my strategy, or propose a better one. I'm asking because not sure it all will work as I expect, don't know if it's the easiest way, and the mistake cost is huge.
Is it what I must do and isn't there a better way out?
I'd carefully perform a baseless merge of all the changes from the branches under release into trunk. I'd do this one branch at a time, and merge "All changes up to a specific version" and select all "Latest Version". That will give you a trunk that contains all of the changes from your releases.
Should I expect conflicts or problems here?
You may get conflicts, but with a bit of care and some forensic investigation of the history, you can get the changes into your trunk.
The normal process when working on release branches (even those not directly related to trunk) is to check into the release branch, then to RI (reverse integration) merge the change back to trunk. Some people prefer to check into trunk first and then merge into the release branch to avoid the situation where trunk may get forgotten about. It's six of one, half a dozen of the other IMO.
Should I remove current "release" and "R***" branches, or leave them as garbage?
I don't think it matters, you could move them into a folder called obsolete releases if you want to hide them, or just delete them - TFS deletes are soft.
Please share your thoughts and concerns on my strategy, or propose a better one
I wouldn't create a stable. Once I had everything in trunk I would be happy, the purpose of a trunk/Main branch is to be the stable releasable version of the code, if the developers cannot keep it that way (I'm not blaming them BTW), then working in feature branches and regularly FI merging into the feature branch is the best way.
Where you go next really depends on the process your company has for releases.
One option is to "label" trunk when you have a release you would like.
Start -----L:R1-----C->
If you then need to put in a bug fix before release, you can branch from the label:
Start -----L:R1-----C->
| /
B:R1 |--C/
Check the change into the R1 branch (B:R1) and merge it back to trunk.
This gives you a branch for releases if needed, but not too deep structure, you may end up with many branches, but you can use folders to keep them organised.
I hope this helps, in closing make sure you read the ALM Rangers branching guide - it covers the main TFVC branching strategies you are likely to need and when you should use them.
And finally, my question to anyone who wants to make a branch is "How will you release this code?", this helps me make branches to solve problems, instead of creating problems. If I don't know how the code will be released, I don't know the best way to structure the branches - I was once involved in a project with a hierarchy of 23 branches off Main, that all ended up coming together before been tested or released - we could have used one :).
Last thing, if you have a VSOnline account or another Team Project Collection, you could try re-creating a simpler version of your problem and experimenting with solutions.
Your merge stratigics looks ok to me but i will try to finish with three branches diagram.
We are using three branches Dev,Test,Release.
most of the builds are from dev and are labeled. (same as trunk at your diagram).
Then we move it to qa and continue development.
If there is an issue \bug and Dev branch is in future development we set test branch to the label and fix the issue on test branch and merge it to dev and again and take label.
If we have an issue with production we use the label on release branch fix the issue, label it and ofcourse merge it to dev.
This how it all done using three branches.
Ofcourse you can always use feature branches for long and defacult features.
Finally, I preformed that merge! Thanks #DaveShaw for recommendations, I mostly used them. But want to publicate my invention which I believe significantly saved time.
Instead of performing a baseless merge from R120 directly into trunk, I created an internediate branch dev, from the common root revision of R120 and trunk and preformed a baseless merge from R120 into dev. That generated more than 600 files with conflicts! But it was easy to resolve them - Take everything from the R120.
Then, since branches dev and trunk have common root, I could merge them with regular merge (not baseless). That performed much-much better than a baseless one and generated only 11 files with conflicts and I could resolve them in only 1 day - all those were real conflicts needing manual resolution and code editing to merge. So that saved me time to distinguish real 11 conflicting files from 600 those which are not a real conflicts and can be resolved automatically.
Next, I will stabilize both branches and switch their roles (it appeared that currently dev plays role of main (stable) and trunk is broken). So I decided to use branching strategy "Development isolation" which will evolve soon to "Development, Feature and Release isolation".
For most of my remaining questions, #DaveShaw provided good explanative answers I have nothing to add to.
The problem I'm facing is that it seems that some of the files generated by Visual Studio are not necessary for commits.
Aside from the obvious things not to commit, what other files should I not commit? Do I need to commit .manifest files, etc.?
A different way of saying it: what files are needed to recreate the project I'm working on, and what files can be auto-generated?
Thanks!
The files I usually don't commit are: *.suo and *.user. I commit most other files.
Binary files can be committed or not depending on your company policy. In theory you should be able to recreate them again from the source code, but in practice it is a good idea to have an exact copy of anything you have sent out to a customer. So at least for releases the binaries should be committed.
In general, its a bit difficult to specifically list the files as it depends a lot on what kind of project you have and tools if any you use for autogeneration of code.
In general, the .suo file is something that is user specific and shouldnt be checked in.
However, the easiest way that i can suggest to you is to
Dont checkin any file that you arent sure u need.
Take a copy of all files from your source control into a fresh location.
Build the solution.
If it builds, great. If not, you then add files till it does.
It is a bit trial and error, but most likely its going to be only a one time thing.
Other option is to actually find out for each type of unknown file exactly what it does and then decide whether it is needed or not and accordingly exclude / include.
For this, if you post the extensions of the files you arent sure of, either google / SO can help!!
Personally, i dont believe in commiting binaries at all, even for releases. Seems unnecessary to me as in our case, every release has a label associated with it. So getting the exact code that was released is just a question of getting the code associated with the label and building it.
Also, since deployment is usually via setup files, as long as you have the setup msi / exe (and as long as you are keeping backups of those for your releases) having all the binaries checked in into source control seems a bit of overkill
I just had a conversation with my manager relating to checkin\out policies on a project I'm currently working on. Basically I tried to edit a file that was already checked out by another developer and I couldn't - I asked my manager why we couldn't edit the same class at the same time and he gave this reason for turning that functionality off: We had a lot of problems with developers editing the same Form (or anything visual done in the designer) and then cheking it in. Merging the changes in the designer generated code was a lot of hassle...
As I'm writing this I'm struggling to see what problem they were having - surely they were getting the latest code before trying to check something in??
Have any of you come across problems with editing the same Form (or something in the designer) as another developer and then checking into TFS? If so how did your team get around the problem? Did you also turn off the ability for developers to work on the same class?
EDIT: The following post (found here) is exactly the problem my manager was describing. Anyone know of a simpler way to resolve the issue than the ones in that post?
I would argue that the solution to your problem would be to establish best practices for source code modification.
Discourage people from going into UI code and arbitrarily jiggling the components around in the designer. Any reasonable UI modifications should be easily mergeable. Your best bet is to try and educate people as to the best way to merge in any given source control system. Also, as helpful as the designer is, ignorance of what code is being automatically generated in the background will be significantly detrimental in the long-term.
People who insist on locking checked-out files for the reasons you stated in your post typically wait long periods of time to check their code in. Naturally, the more time passes, the more code gets modified, so it makes merging difficult for these people. Checking in early, often, and incrementally requires people to think about their changes in stages, and for some coders, this is a rather painful cultural/psychological adjustment.
I've just checked back through the histories of some of my .designer.cs files and I can't see any changes that would cause a merge problems. There were no wholesale rearrangements of code for example.
Another thing to consider is to make sure that everyone does a "get latest" at regular intervals then any individual merge/resolution isn't going to be that great thus minimising the chances of anything going wrong.
It might also be worth investigating a 3rd party merge tool. There are plenty around.
Now it could be that the changes I've done are simple compared to the ones you've got so you should take my anecdotal data with a pinch of salt.
It can cause problems (in general) when a lot of people are editing UI concurrently. The merge logic will do a fine job merging things, but in a lot of cases the UI is drawn according to how things are added to the form. Your UI can get messed up quickly.
I don't know if I would use this as an excuse to enforce exclusive checkouts across the board, though. I might go from a (non programmatic) policy standpoint that says shared checkout for business logic, but exclusive for UI changes.
I would couple that with a strong MVP, MVC, or MVVM approach, though, which should limit the number of people that have to touch the UI concurrently.
As others have alluded to, keep one of the seminal rules of SCM in mind: merge early and often, and your problems are reduced. (along with that is "always get latest before you start working on the code).
I'm a beginner so if there is a terminology for what I'm doing I don't know how to search for it. So forgive me if this has been asked before. So here is what I do. Before I make any major code changes, I make a copy of the projects folder and call it "project v6" for example. Then if I really mess things up and cant find a way to undo it, I just go back to the previous folder. This has been working well enough for me but sometimes I forget to do this and have to take 2 steps back. Is there an easier way to do this than the way I am now?
There are many source control tools, which keeps track of all this stuff. Git, subversion, cvs (used wikipedia links, which explains each with more detail. This can be done much more easily once you get used to them.
In both there is commit what you've done to a server (which may be your own machine). But you can store your code somewhere else (so you don't lose everything, in case your hard disk fails or something like that). Google Code is a good example.
Git - harder to use, but very powerful (more used when there are lots of people working on the same project, and even the same file sometimes), much easier to deal with branches and stuff like that (if you don't know what that is, so you probably don't need it yet)
svn (subversion) and cvs - simpler to use, with fewer resources available. Probably enough for your needs
What you're looking for is revision/source control software.
http://en.wikipedia.org/wiki/Revision_control
I absolutely agree you need to start using a source control system. Even if for no other reason than to ingrain good work habits, you will be required at some point to use a source control system.
Having said, if your IDE is Visual Studio (non-express editions) you can use an addins to:
zip the sln for you, such as codeproject - zipstudio
or
keep a "local file history à la Eclipse" visual local history