I am looking to start a project with distributed source control and am evaluating the different options. Looking at Bazaar, I stumbled over several articles (e.g. this) that development has slowed down significantly.
What is the status of the project bazaar? Are bugs getting fixed?
I will try to answer first with facts.
1/ According to the Active (published) Bazaar branches of Bazaar, we can see that there is 8 active development branches (changed since beginning of 2013)
2/ According to Bazaar 2.6b3 milestone, 3 bugs out of 12 are fixed for the next 2.6b3 release. This version started 6 month ago (August 2012).
3/ According to Bazaar v2.5 series, v2.5 series had a beta/minor release every month.
4/ According to Bazaar v2.6 series, v2.6 series has a beta/minor release every 4 months (well, there are not so many releases to give trends here).
5/ Bazaar is still used on prestigious/ambitious/large projects : Ubuntu, Debian, MySql , Launchpad ... projects that are active in the Bazaar community.
So the first observation is that releases are less frequent, clearly.
One may think it's bad trends, but one can consider that the application is now mature enough and that new road map (with new features) needs to be forecast.
To finish, here is an extract of a IRC chat I had with bzr team. This may point out the issue with intermediate release.
trident_job: Hi there. I've seen that latest bzr version is v2.6.2
and is 1 year ago (nearly).
trident_job: next version v2.6.3 still
have 3 bugs to fix ... do you think the project is stall ?
mmm: we lack anyone who's job it is to do the release these days
mmm: you're right that there's stuff on trunk that could have done with being
released a good while ago
trident_job: mmm: yeah, that's not good
advertisement for an open source project to have 1 year release cycle
mmm: well poked... so, probably an rt unfortunately
UPDATE 2013.09.20 : Bazaar retrospective from a dev.
Read especially the last two chapters :
Bazaar on the slow track
Conclusion
Related
I recently started taking an interest in using a branching model similar to Vincent Driessens Git branching model. We have multiple developers working on the same project so using different branches for different features is a big plus for us. The model states that after a feature is developed, it is merged back into the Development branch, and on a certain time a release branch will be created from it.
Now my problem is that I don't know who added what to the dev branch since the last release, but I do want to present a list of changes that will be implemented for the next one. So the question is, how do I know what features have been added to the dev branch?
We're using TFS for version control. As far as I know I have the following options:
Better labeling and commenting of versions (currently there is no labeling and little commenting)
Linking TFS tasks to versions (not sure how to create a nice list of that yet though)
Maybe I should just follow my own options above but I was curious about how you guys deal with this.
First I would suggest you take a look at the TFS Branching and Merging Guide as it will likely answer most of your questions.
how do I know what features have been added to the dev branch?
I think the "develop" branch in Driessen's model is most closely equated to the "main" branch in the TFS guidance. I would suggest that you shouldn't merge changes into main unless they are already planned to go into the next release. Then when you are ready to release you simply branch from the latest version of main.
Keeping track of what features are intended for the next release is something that would be handled by the work item tracking system.
Separately, you may find the Track Work Item feature of Team Explorer to be helpful.
One of the products which I have been working started some 10 years back. There were several developers who had worked for this project and several merges had happened throughout the life time of this project. Now taking the version information (clear case version tree), applying labels, checking out are taking long time. Is it a good idea to delete old branches and (say like 3 years back) to improve the maintainability of the code and performance of the version control? We're using clear-case as version control
If you are using ClearCase with UCM, then deleting a branch (which is only possible if you delete every versions on that branch for every file) isn't a good idea.
And with base ClearCase, it is still tricky and quite complex to properly remove everything.
Start first by obsoleting those branches and see if that speeds up operations like mkelem or lsvtree.
See cleartool lock -obs.
I am part of a team that releases versions of our software 4-5 times each year to our customers. We maintain the previous 2-3 versions of our product by correcting any errors that we come across in later versions. We are using TFS 2008 for source control and are trying to find the best way of maintaining the older versions.
We currently create a branch of our application each time we do a new version, but we are looking for a good way to update old versions more easily. For example, we complete 9.5 but two weeks after we created the branch and are working on 10.0, we realize that 9.5 has an error. We currently make the change in version 10.0 and then open 9.5 to make the change again. Is there anyway of automating this?
Thanks!
This is a main reason for branching and merging.
What I do in your situation is to make the change in 9.5 and then merge the change up into your main branch, and then back down into your 10.0 branch. The built in merge tool works well for this.
If you go the other direction you run the risk of adding new 10.0 stuff into your 9.5 branch when all you want is your bug fix.
I would also take a look at the TFS Branching Guides for more information on branching and merging.
If you are creating a branch of your main source, then you should be able to make the correction to the bug in your main source and then "merge" that change to your 9.5 and 10.0 branches. That's part of the beauty of branching, namely, you can merge your changes from your main branch to the target branches.
When you choose the merge option with TFS, it will show you where the current source is branched, and you can choose which branches you want to merge those changes to. You shouldn't have to make the changes in your 9.5 and 10.0 branches manually, that really sort of defeats the purpose of branching in the first place.
No, there is no way to "automate" this, and you dont really want to. What if the fix doesnt really need to be applied to each version?
It does sound to me like you are applying fixes backwards (first fix in older versions, then merge to newer).
I have been tasked with coming up with a strategy for branching, merging and releasing over the next 6 months.
The complication comes from the fact the we will be running multiple projects all with different code changes and different release dates but approximately the same development start dates.
At present we are using VSS for code management, but are aware that it will probably cause some issues and will be migrating to TFS before new development starts.
What strategies should I be employing and what things should I be considering before setting a plan down?
Sorry if this is vague, feel free to ask questions and I will update with more information if required.
This is the single best source control pattern that I have come across. It emphasizes the importance of leaving the trunk free of any junk (no junk in the trunk). Development should be done in development branches, and regular merges (after the code has been tested) should be made back into the trunk (Pic 1), but the model also allows for source to be patched while still under development (Pic 2). I definitely recommend reading the post in its entirety, to completely understand.
Pic 1
Pic 2
Edit: The pictures are definitely confusing without words. I could explain, but I would basically be copying the original author. Having said that, I probably should have selected a better picture to describe the merge process, so hopefully this helps. I'd still recommend reading the post, however:
The simplest and most usual way I've seen branching work is off two premises. Trunk and Release. I think this is known as the "Unstable trunk, stable branch" philosophy.
Trunk is your main source. This contains the "latest and the greatest" code and is forward looking. It generally isn't always stable.
Release is a one-to-many association with trunk. There is one trunk but many releases that derive from the trunk. Releases generally start with a branch of the trunk once a particular functionality milestone has been hit so the "only" things left to go in for a particular deployment should just be bug fixes. You then branch the trunk, give it a label (e.g. 1.6 Release is our current latest Release), build and send the release to QA. We also push the version number (usually the minor number) of the trunk up at this point to ensure we don't have two releases with the same number.
Then you begin the testing cycle on your release branch. When sufficient testing has been perfomed you apply bug fixes to the release branch, merge these back to the trunk (to ensure bug fixes are carried forward!) and then re-release a build of the branch. This cycle with QA continues until you are both happy and the release is finally given to the customer(s). Any bug reports from the customer(s) that are accurate (i.e. they are a bug!) start another QA cycle with the branch in question.
As you create future releases it is a good idea to also try to move older customers onto newer branches to reduce the potential number of branches you might have to back-patch a bug fix into.
Using this technique you can deploy solutions using your technology to a variety of customers that require different levels of service (starting with least first), you can isolate your existing deployments from "dangerous" new code in the trunk and the worst merge scenario is one branch.
My first recommendation would be to read Eric Sink's Source Control HOWTO - specifically the branches and branch merge chapters.
We have 3 containers - DEV, MAIN, and RELEASE for our work. MAIN contains all our "ready-to-release" code and we tend to think of it as "basically stable." DEV/Iteration (or DEV/Feature, or DEV/RiskyFeatureThatMightBreakSomeoneElse) are branches from MAIN and are merged up when the Iteration/Feature is ready to promote up past the DEV environment. We also have TFS builds set up from the DEV/Iteration branch and the MAIN branch.
Our RELEASE container contains numbered releases (similar to the "tags" container used in many Subversion repositories). We simply take a branch from MAIN each time - I like to say we're "cutting" a RELEASE branch to signify this shouldn't have a lot of activity going on once the merge is finished.
As for VSS->TFS - Microsoft supports an upgrade path which should keep your version history, but if you don't need it the history, I would just get the latest version from VSS, check it into TFS and archive the VSS repository.
One final tip - get your team members familiar with source control. They must understand branching and merging or you will be stuck doing a lot of cleanup work :).
Good luck!
The subversion book describes some common branching patterns. Maybe you can also apply these to TFS.
My team is working with VSS and we are having difficulties managing versions:
We want to take a "snapshot" of the project we're working on, so we can keep working on it, but when we need to - we can get the files of the snapshot and built them for a release. (Is that called branching?)
Alternatively, getting all project files by date would be great too. (Meaning I would get the last checked-in version of each file in the project prior to the specified date.)
Is there any tutorial regarding this? I searched the net a bit and only found very simple howto's.
Thanks.
As Cannonade wrote, a label might be what you want. But since you explicitly mentioned branching in your question, you should be aware of the differences between a label and a branch:
With a label, you simply mark the current state of all files in your source safe database (the repository). If you created a label "V1.0", you can now at any time easily retrieve exactly that state and rebuild the V1.0 release for example.
With a branch, you create a copy of the current state of your repository. E.g. if you create a copy named "1.0", you can then continue with the development e.g. towards V2.0. Should you ever need to fix a bug for V1.0, then you can do this on the "1.0" branch.
So branches should be used to work on different versions of your projects in parallel. Labels should then be used to mark special versions on your branches (e.g. the ones used to create a release).
One last note: SourceSafe does not have a specific "branch" command. Instead you "Share" your solution and select the option "Branch after share". You can find more information about it in MSDN.
And a very last note: We stopped using SourceSafe about 1.5 years ago and switched to subversion (which is opensource and free). Have a look at subversion or other solutions. I can not imagine ever going back to SourceSafe.
You can apply a label to a current snapshot of source safe (like BUILD1) and then get the tree based on that label at a later date.