If we need to issue a bug patch that does not include current development that has been committed, or any changes from their current version, what should be done to make the process safer and with lower overhead?
We are currently using Subversion for our source control in a small (3 developers) team primarily developing in Visual Studio 2008. We anticipate that the team may group to 8 developers over the next year, and for any previous release support to become more complicated. While most customers are on the current release, some are further behind.
Source control can handle this pretty easily, and was designed for this.
When you reach the stabilization period of your release a branch should be done. It is important that you do not start any work on the next release before this is done.
Any bug fixes for that release should be done in that branch. This prevents new code from an upcoming release from polluting the bug fix. Once the bug fix is done then you can merge that change down to the trunk, and any other releases as necessary.
Don't forget to put the bug number in the comment, as this will make keeping track of commits easier.
How about: a branch per major version, with bug fixes applied to the branch(es) as needed, and also applied (or merged) back to trunk.
Where I work, we have several projects working simultaneously. In order to avoid this issue, we have several variants of the source code. For example, the first release is Variant 1.0. We create a branch off of this release, say, Variant 2.0, for all future development. If we need to do a bug fix, we do it on the main Variant, which is currently 1.0 and can release that. When Variant 2.0 is ready to go to production, we merge it with whatever is on the main branch (in this case, 1.1) and that becomes the new main trunk. At one point, we had 4 branches running at the same time.
Merging the code can be time consuming, and you have to be careful not to introduce new bugs during the merge, but if you have a decent code comparison tool available, then it shouldn't be too bad. We did a merge a while back using Beyond Compare on a 10,000 file source directory, and it took a single morning.
Related
I am using VS2013 TFS, my scenario is
1'st version of code checked in TFS and released. (Local Path is
C:\Development\DEV )
2'nd version coding started and not completed.
Now client is asking issue fix on top of first version ? how to do that ?
The same issue fix should be included in 2nd version also. how to do?
Assuming you have no branches yet, it goes something like this:
Get History on your main (v2) branch and work out the changeset or date/time at which you originally built v1.
Right click your main branch (v2) and create a new branch (for v1). Choose "from a changeset" or "from a date/time" and enter the information from the first step to identify where (or rather when) the branch should be taken from. Commit this branch. You mow have two separate independent branches, with the v1 branch using the historical code you had for the v1 release, and your main branch still containing v2.
Now you can fix the issue, in either branch. You will need to use the Source Control explorer to map both the branches into separate folders your PC so that you can work on them. (If your source code is not relocatable then you will have to switch between the branches by remapping them to the same location. This can be confusing but not too difficult if you do things carefully and make sure you get a clean copy of a branch before you start working on it. The pain of this is a good way of learning to make your code relocatable the next time :-)
Now you need to replicate the fix in the other branch. If the branches are quite different you may find it easier to just write the fix a second time in the other branch, or you can right-click on the fixed branch and Merge into the second branch. TFS will do as much as it can for you but you will then need to resolve any merge conflicts to apply the changes you made for your fix to the second branch without breaking anything. (This can be quite tricky, so take care, and if you are unsure remember that you can undo your changes and re-start the merge at any time)
Once you have finished the fix and tested your merged code locally, diff it once more against the previous/workspace version to be sure that you can's see anything you might have screwed up in the merge, and then check it in.
Finally, if your release needs to be built by your build server, then you will need to point your build system at the v1 branch to get it to build the (fixed) v1 version for a new release (for a once-off build you just have to redirect your source control mappings for the v1 branch so that the build server gets from v1 instead of v2 when it 'Gets' the source code from source control, and when you are finished, remap the source back to the v2 branch)
As long as you think through each step and take care, it's fairly straight forward. But if you have never done it before, I suggest you work through each of the steps above and do some searches to learn more about how to branch, how to map source control folders, and how to merge.
Branching and merging is a complex topic and there are many patterns that you could follow. Without knowing more about your requirements it's impossible to give you good advice. You need to consider things like: How many clients consume the code. Is this for a shrink wrap application with multiple versions available concurrently or a production system where there is only 1 version "live" at one time. You'll also need to take in to account how you test your code (environments etc) and what kind of build process and deployment process you have.
The best advice I can give you without more information is to read the ALM Rangers guidance on TFS version control. Then come back with more specific questions. Also, keep it simple, don't over think it or you'll get in to a mess.
I will start by saying this is probably a dumb question so apologies if I am staring at the answer but cannot see.
I have used VCS in the past primarily as a method of allowing me to revert my code if something goes wrong. I have always had a single lime of development. However I get into the usual trouble when releasing and starting the next version - dealing with bugs. So this time I decided to use branching (forking or whatever is the best name). I am a lone developer so I am the only one working with the repositiory. My scenerio is simple. I want to create a branch when I release so that I have a line for the released code and a line for the beta. I can then work happily on the beta. Now a bug comes in and I need to get back to the last commit for the release.
My question is what is the best way to get back that code in the IDE to work on it.
I have read that in Mercurial a simple way is to clone the repository including the working directory. This would give me two copies of the code base and I guess I can choose which one to load into the IDE. I would then use Push or pull to get the bug fixes from the release copy into the beta copy (I think).
I assume there must be another way however without cloning. How would I do that? I can guess at reverting to the last commit of the release code. Then I assume that loading the solution into the IDE would give me that. I am not sure where I would go from there when the code is done.
For the record I looked at a number of different VCS - I have used SVN in the past but wanted to go to a DVCS. I looked at Git, Bazaar, Mercurial and Veracity (and used Code-Coop in the past). You may think another tool would suit my needs better. Having tried the others however I found I could understand the way Mercurial works and the GUI tools such as TortoiseHg with the WorkBench and HgSccPackage (http://visualstudiogallery.msdn.microsoft.com/9bc074fa-9e1f-4ce2-a75d-b90e65f7475a) appeal
There are a lot of good documents and links here Introduction to Mercurial and I have read about different ways to branch that include using bookmarks and so on but they seem primarily targeted at multi member teams - which make sense of course
Many thanks in advance
You are mixing concepts a little, i guess you have SVN background ?
Just to answer you question, to 'get back the code in IDE' you will need to 'update' to a previous version. But this is considering you already have cloned the repository. Is your question about how to clone.. ? As you ask, there is no other way without cloning first. Cloning is the first step towards having a HG repository local. After clone, you can commit and push changes or pull and update.
To expand the answer even further and given that you are going to use Mercurial, here is what you should do:
read this : http://hginit.com/ - great HG (tutorial) by Joel Spolsky him self ! An introduction into HG and the concepts. You will need to understand this very good, since right now you are doing a lot of guessing, assuming and thinking :) HG/Git is different from SVN and in the begging the concepts might be hard to understand and to get used to.
for your project and regarding your question, have a branch called 'dev' or 'trunk' or 'version X' etc where you will commit all new changes.
have a branch called 'live' etc that will represent the current 'live' version. This way, whenever you need to revert back in time to the live version and to do a quick fix on it, you will 'update' to the tip of that 'live' branch, discarding all local changes (after you have committed to trunk! of course).
when putting a version to live, you will need to (assuming all changes are committed !) : update to the live branch then MERGE the version X into local (local being live ). This will include your versionX branch into live - it's what you need at this point. Then, either update back to version X branch or create a new branch - version X+1. This will take care of the versions and keeping the branches separate.
since you are using VS - install http://visualhg.codeplex.com/. HG source control integrated into VS.
I assume there must be another way however without cloning
Yes. You can use (named) branches inside single repo (I prefer HgSccPackage in VS), update to revisionbranch head, change, commit, merge
BTW, branching with bookmarks/clones/branches work the same (good) way for any size of team - it's a matter of taste
My scenario is pretty straight-forward. I am working on a long assignment locally on my computer, working off of a code branch from TFS. Along comes the boss, and I need to push through a bug fix. Is there any clean way to change contexts? This long assignment has updated a lot of files, and I want to make sure I implement the bugfix from a clean slate.
If I were using Git, I know what to do: create a new branch from main, fix bug, check in, change back to previous branch, but TFS doesn't really work that way. Any ideas?
If you don't want to commit the changes you 're working on yet, your first step is to shelve them - that's pretty straightforward.The next step is to decide where you 'll be implementing your urgent request. This depends on
How you have set up your branching scheme in source control (see here for a great resource ), &
The line where the error was reported
'Boss'-bugs tend to be reported from Release-Lines, taking this as a given you would have to:
Identify the latest changeset that corresponds to the version your problem was reported
Track this changeset to a version in the branch you can work on (I suppose you can't make changes directly on your release line, right)
Make a branch & implement the change. Your build-environment should ensure that all tests & checks ensure that your issue is fixed & that no others have emerged.
Your next challenge is how you 'll propagate these changes to a new Release - This greatly depends on how you ship software to the customer (Hotfixes? Patches? Service Packs?), as well as the severity of the issue.After you 've settled everything back to normal, unshelve & continue working on your long-term task.
This question mixes a bit of project management as well as development. I understand the [major].[minor].[patch] scheming for version numbering of a project. With my clients' projects I use these numbering primarily for internal purposes so instead of refering to a project by the features involved, the team can say "what is the progress of v1.3.2?".
However, sometimes our clients have multiple minor releases at once. Each minor release contains a set of independent features (working with different departments of the client company), but both could launch different times. So if we label them as v1.3.3 and v1.3.4, the v1.3.4 version could release earlier than v1.3.3 and then the whole naming scheme is invalid.
How do you refer internally to these various builds if you don't know which will release first (due to waiting for client approval, or other external scheduling conflicts)?
Thanks!
Pretty simple -- we don't assign version numbers until we release. Problem solved!
That may sound flippant, but it's the truth. Sure, we would have internal projects dubbed e.g. "v5.5", but those were separate and independent from current work on the next iteration of v5.4.x, which would receive the next value of 'x' only upon completion and release. When v5.5 is ready, work on 5.4 ceases, we merge any changes made to 5.4 into 5.5, and then we release 5.5.0.
If you have separate builds for different clients (departments in your case), you can employ a modified versioning scheme. What we did is use [major].[minor].[client].[patch], e.g. 5.4.client1.4. The [patch] would be independent and only meaningful to that particular client, whereas [major].[minor] would correspond to the [major].[minor] version of the main codebase from which we forked off. For example, we might have simultaneous work on 5.5, 5.4.x, and 5.4.client1.x. When 5.5 is ready, 5.4.x merges into that, and then both projects fold into 5.5.x, but the client project might not be ready to merge all those changes and thus it would remain 5.4.client1.x until it was brought up-to-date with 5.5, then becoming 5.5.client1.x.
This may sound confusing, but it actually worked very well for us. We previously employed a variation of this scheme, where the client name was appended to the complete version number, i.e. [major].[minor].[patch]_[client]; again, however, [major].[minor] corresponds to the "core" [major].[minor] from whence it was forked/last merged, and the [patch] is wholly independent from the other versions and only meaningful to that client (this is why we later swapped the relative positions of [client] and [patch], to make it clear that e.g. 5.4.7 might actually have more fixes/be more "current" than 5.4.12.client1, and to better communicate that independence.
When a client-specific project merges back, of course, you drop it and increment to the next [patch], or perhaps make the jump up to the next [minor] or even [major] version, depending on the nature of the work. This does occasionally lead to some temporary confusion when a client project merges into the 5.4.x project and then we release from that version 6.0, then remember to rename the internal 5.5 project to 6.1, but it worked nonetheless.
As an alternative for your environment, internally refer to your current projects simply by client (department) name, e.g. the Accounting project, the HR project, etc. Don't use version numbers internally for this kind of thing, because as you see it just leads to confusion like version 5.4.6 coming out after 5.4.7 but before 5.4.9; meanwhile 5.4.8 never gets released because it was canceled. That's just a mess, so stay away from that. Simply call your projects by client name, and assign the next number
I've used source controls for a few years (if you count the Source Safe years), but am by no means an expert. We currently are using an older version of Sourcegear Vault. Our team currently uses a check out and lock model. I would rather switch to a update and merge model, but need to convince the other developers.
The reason the developers (not me) set up to work as check out and lock was due to renegade files. Our company works with a consulting firm to do much of our development work. Some years ago, long before my time here, they had the source control set up for update and merge. The consultants went to check in, but encountered a merge error. They then chose to work in a disconnected mode for months. When it was finally time to test the project, bugs galore appeared and it was discovered that the code bases were dramatically different. Weeks of work ended up having to be redone. So they went to check out and lock as the solution.
I don't like check out and lock, because it makes it very difficult for 2 or more people to work in the same project at the same time. Whenever you add a new file of any type or change a file's name, source control checks out the .csproj file. That prevents any other developers from adding/renaming files.
I considered making just the .csproj file as mergable, but the Sourcegear site says that this is a bad idea, because csproj is IDE auto-generated and that you cannot guarantee that two different VS generated files will produce the same code.
My friend (the other developer) tells me that the solution is to immediately check in your project. To me, the problem with this is that I may have a local copy that won't build and it could take time to get a build. It could be hours before I get the build working, which means that during that time, no one else would be able to create and rename files.
I counter that the correct solution is to switch to a mergable model. My answer to the "renegade files" issue is that it was an issue of poor programmer discipline and that you shouldn't use a weaker programmer choice as a fix for poor discipline; instead you should take action to fix the lack of programmer discipline.
So who's right? Is check in - check out a legitimate answer to the renegade file issue? Or does the .csproj issue far too big of a hassle for multiple developers? Or is Sourcegear wrong and that it should be ok to set the csproj file to update and merge?
The problem with update and merge that you guys ran into was rooted in a lack of communication between your group and the consulting group, and a lack of communication from the consulting group to your group as to what the problem was, and not necessarily a problem with the version control method itself. Ideally, the communication problem would need to be resolved first.
I think your technical analysis of the differences between the two version control methodologies is sound, and I agree that update/merge is better. But I think the real problem is in the communication to the people in your group(s), and how that becomes apparent in the use of version control, and whether the people in the groups are onboard/comfortable with the version control process you've selected. Note that as I say this, my own group at work is struggling through the exact same thing, only with Agile/SCRUM instead of VC. It's painful, it's annoying, it's frustrating, but the trick (I think) is in identifying the root problem and fixing it.
I think the solution here is in making sure that (whatever VC method is chosen) is communicated well to everyone, and that's the complicated part - you have to get not just your team on board with a particular VC technique, but also the consulting team. If someone on the consulting team isn't sure of how to perform a merge operation, well, try to train them. The key is to keep the communication open and clear so that problems can be resolved when they appear.
Use a proper source control system (svn, mercurial, git, ...)
If you are going to do a lot of branching, don't use anything less recent than svn 1.6. I'm guessing mercurial/git would be an even better solution, but I don't have too much hands-on-experience using those yet.
If people constantly are working on the same parts of the system, consider the system design. It indicates that each unit has too much responsibility.
Never, ever accept people to offline for more than a day or so. Exceptions to this rule should be extremely rare.
Talk to each other. Let the other developers know what your are working on.
Personally I would avoid having project files in my repository. But then again, I would never ever lock developers to one tool. Instead I would use a build system that generated project files/makefiles/whatever (CMake is my flavor for doing this).
EDIT: I think locking files is fixing the symptoms, not the disease. You will end up having developers doing nothing if this becomes a habit.
I have worked on successful projects with teams of 40+ developers using the update-and-merge model. The thing that makes this method work is frequent merges: the independent workers are continuously updating (merging down) changes from the repository, and everyone is frequently merging up their changes (as soon as they pass basic tests).
Merging frequently tends to mean that each merge is small, which helps a lot. Testing frequently, both on individual codebases and nightly checkouts from the repository, helps hugely.
We are using subversion with no check-in/check-out restrictions on any files in a highly parallel environment. I agree that the renegade files issue is a matter of discipline. Not using merge doesn't solve the underlying problem, what's preventing the developer from copying their own "fixed" copy of code over other people's updates?
Merge is a pita, but that can be minimized by checking in and updating your local copy early and often. I agree with you regarding breaking checkins, they are to be avoided. Updating your local copy with checked in changes on the other hand will force you to merge your changes in properly so that when you finally check-in things go smoothly.
With regards to .csproj files. They are just text, they are indeed mergeable if you spend the time to figure out how the file is structured, there are internal references that need to be maintained.
I don't believe any files that are required to build a project should be excluded from version control. How can you reliably rebuild or trace changes if portions of the project aren't recorded?
I am the development manager of a small company, only 3 programmers.
The projects we work on sometimes take weeks and we employ the big bang, shock and awe implementation style. This means that we have lots of database changes and program changes that have to work perfectly on the night that we implement. We checkout a program, change it and set it aside because implementing it before everything else will make 20 other things blow up. I am for check out and lock. Otherwise, another person might change a few things not realizing that program has had massive changes already. And the merge only helps if you haven't made database changes or changes to other systems not under source control. (Microsoft CRM, basically any packaged software that is extensible through configuration)
IMO, project files such as .csproj should not be part of the versioning system, since they aren't source really.
They also almost certainly are not mergeable.