Related
I've been tasked with setting up a version control for our web developers. The software, which was chosen for me because we already have other non-web developers using it, is Serena PVCS.
I'm having a hard time trying to decide how to set it up so I'm going to describe how development happens in our system, and hopefully it will generate some discussion on how best to do it.
We have 3 servers, Development, UAT/Staging, and Production. The web developers only have access to write and test their code on the Development server. Once they write the code, they must go through a certification process to get the code moved to UAT/Staging, then after the code is tested thoroughly there, it gets moved to Production.
It seems like making the Developers use version control for their code on Development which they are constantly changing and testing would be an annoyance. Normally only one developer works on a module at a time so there isn't much, if any, risk of over-writing other people's work.
My thought was to have them only use version control when they are ready to go to UAT/Staging. This allows them to develop and test without constantly checking in their code.
The certification group could then use the version control to help see what changes had been made to the module and to make sure they were always getting the latest revision from the developer to put up on UAT/Staging (now we rely on the developer zip'ing up their changed files and uploading them via a web request system).
This would take care of the file side of development, but leaves the whole database side out of version control. That's something else that I need to consider...
Any thoughts or ideas would be greatly appreciated. Thanks.
I would not treat source control as annoyance. See Nicks answer for the reasons.
If I were You, I would not decide this on my own, because it is not a
matter of setting up a version control software on some server but
a matter of changing and improving development procedures.
In Your case, it might be worth explaining and discussing release branches
with Your developers and with quality assurance.
This means that Your developers decide which feature to include into a release
and while the staging crew is busy on testing the "staging" branch of the source,
Your developers can already work on the next release without interfering with the staging team.
You can also think about feature branches, which means that there is a new branch for every specific new feature of the web site. Those branches are merged back, if the feature is implemented.
But again: Make sure, that Your teams agreed to the new development process. Otherwise, You waste Your time by setting up a version control system.
The process should at least include:
When to commit.
When to branch/merge.
What/When to tag.
The overall work flow.
I have used Serena, and it is indeed an annoyance. In addition to the unpleasantness of the workflow overhead Serena puts on top of the check in-check out process, it is a real pain with regard to doing anything besides the simplest of tasks.
In Serena ChangeMan, all code on local machines is managed through a central server. This is a really bad design. This means a lot of day-to-day branch maintenance work that would ordinarily be done by developers has to go through whomever has administrator privileges, making that person 1) a bottleneck and 2) embittered because they have a soul-sucking job.
The centralized management also strictly limits what developers are able to do with the code on their own machine. For example, if you want to create a second copy of the code locally on your box, just to do a quick test or whatever, you have to get the administrator to set up a second repository on your box. When you limit developers like this, you limit the productivity and creativity of your team.
Also, the tools are bad and the user interface is horrendous. And you will never be able to find developers who are already trained to use it, because its too obscure.
So, if another team says you have to use Serena, push back. That product is terrible.
Using source control isn't any annoyance, it's a tool. Having the benefits of branching and tagging is invaluable when working with new APIs and libraries.
And just a side note, a couple of months back one of the dev's machine's failed and lost all his newest source, we asked when the last time he committed code to the source control and it was 2 months. Sometimes just having it to back up stuff when you reach milestones is nice.
I usually commit to source control a couple of times a week, depending if I've hit a good stopping point and I'm about to move on to something different or bigger.
Following on from the last two good points I would also ask your other non-web developers what developmet process they are using so you won't have to create a new one. They would also have encountered many of he problems that occur in your environment, both technical using the same OS and setup and managerial.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have the opportunity to give a formal presentation to my boss about anything that benefits the company. My idea is to adopt source control in my workplace. I have been using Mercurial to manage my own project at work, but the rest of the team does not have a formal source control system in place. Unfortunately, I'm not very good at presenting ideas.
So, can you guys tell me why developers MUST use source control? Additionally, why would you choose any tool except Visual SourceSafe? I don't have experience using VSS, but he is likely to ask why we wouldn't just use Microsoft's tools.
I want to hear opinions from the many smart programmers here! My preferred options are SVN or mercurial. Both seem to have good support for their Windows versions, and both are less archaic than CVS. Also, as a self-declared open source disciple, I would prefer to suggest an open-source tool. :)
Thank you!
Edit: To make it short, generally, current practice for other developers is copying folder, tag with date and maybe record on their own. You get the picture. What if my boss says "if it works, why fix it?"
Let's compare two examples, one development environment that uses source control, and one that doesn't.
A: Does Use
B: Does not Use
Scenario 1: A project is requested, completed, and rolled out
A + B) Programmers develop the project internally, when it's completed, push it out to testing, and then deliver to the client (whoever that may be)
Not much difference, in the big picture
Scenario 2: After a project is released, the client decides that they don't want feature X
A + B) Developers remove the code that the client doesn't want, test, and deliver.
Again, not much difference.
Scenario 3: Two weeks later, the client decides that they actually DO want feature X
A) Developers reintegrate the code they took out in 2 back into the normal development tree, test, and deliver.
B) The developers search for the old code on their personal machines, the file server, and backups. If they find the code, they must manually reinsert each file. If they do not, they probably have to recode that entire feature.
It's easy to get old code that you took out for one reason or another
Scenario 4: There's a strange bug in the system where a function is supposed to return a boolean result, but always returns false. It wasn't like that two weeks ago.
A) Developers examine all the old versions of the software, and figure out that a return false directive isn't in the proper scope - it's executing inside a loop instead of outside.
B) Developers spend weeks trying to figure out what the problem is. Eventually, they notice the return on the wrong line, and fix it. Not having source control means they had to examine each and every file that was executed, rather than finding the differences from when it was working and now.
Scenario 5: Someone breaks the build. It gets past testing and is only noticed weeks later.
A) The team examines the commit history, finds out who broke the build, makes that person fix it and buy the team dinner.
B) The team has to go back through the entire project to find the error, but can't figure out who put that code in. Developers blame each other, and the team dynamic fails.
It's easy to see who committed what, when, and why.
Use source control because neither you nor your team are perfect. The primary function of source control is to ensure that you have a complete historical record of your development process. Having this record, you have the ability to confidently branch out with "experimental" versions, knowing that if the experiment fails, you can back up to an earlier version.
In addition, a good source control system like svn will permit multiple developers to work on the same file and provide powerful tools for reconciling the differences that each introduces.
Simply - so you have a true history of the code - to investigate changes (reasons for bugs), revert to versions, audit, etc. Backup isn't enough - you simply have a copy of the current picture. Ever change a file and wish you could remember what you did?
You have to use Source Control for these reasons
1) You can rollback to any version
2) Different developers can work on the same files
3) All developers, will have access to the same code base
4) You can track changes
5) You can rollback changes that don't work
6) Source control is the basis of continuous integration and helps massively with TDD
7) If you don't use source control, you will slowly go mad as files get lost/overwritten and nothing works as it should
VSS is not the worst SCC application, I used it for years and grew to hate it, but it does work, is simple, and many people know it.
Here's a simple real-life example.
A few years ago, my boss says, "Feature XYZ used to work, and now it doesn't. No one knows what happened. Can you fix it?"
Now I've never worked with feature XYZ before. So fixing it would involve a lot of flailing around trying to figure out what it does.
But we have source control! So I do this:
Create a test script to test feature XYZ: "Click here, type this, click there, etc."
Get current version. Build. Test. Feature XYZ is broken.
Get version from a week ago. Build. Test. Feature XYZ works.
Get version halfway between those two. Build. Test. Feature XYZ works.
Get version halfway between previous one, and current one. Build. Test. Feature XYZ is broken.
I kept doing this binary search until eventually I hit the point of change: version 145 (we'll say) had the feature working, but version 146 had it broken. Then I just did a compare between those two versions to see what changed. Turns out our technical lead (sigh) had checked in code that changed functionality, but also introduced a side effect that broke feature XYZ.
So I removed the side effect, tested...and lo and behold, feature XYZ worked again.
Without source control, you can never do this. You'll have to flail around, changing one thing or another, hoping to magically hit on the thing that makes feature XYZ work again.
With source control, you just test your way through the versions, pinpoint the exact code that caused the problem, and fix it.
Microsoft (MSDN) has a good article on the benefits of source control.
http://msdn.microsoft.com/en-us/library/ms173539.aspx
There are also lots of good questions here on SO as to the pros and cons.
What are your pros and cons of git after having used it?
Subversion is very popular, but Git is going to be the "next big thing" in the source control world.
It seems to me that most people have covered the major feature of source control but one of the biggest positives is skipped over. These are:
Branches
Without a source code repository it is impossible to create branches (or copies/stream/etc.) of your code for particular purposes. Not being able to create and merge branches is one of the biggest things that disqualifies VSS from being a real source code control system. Some of the purposes of a branch include:
Bug Fix
Sometimes you need to resolve a bug and do it in a place away form the mainline or trunk version of your code. This may be to resolve a problem in the testing environment or any number of reasons. If you have a version control tool you should be able to easily make a new branch (something VSS sucks at) to fix the bug and be able to merge it back into the mainline code if necessary
Maintenance Release
This could be much the same as a bug fix but done after code has been released to production. Examples would be for fix packs, service releases, etc. Again, you want to be able to merge the changes back into the trunk if necessary
New Feature
Sometimes you need to start development of a new version while maintaining your current code. For example you release and maintain v1.0 but need to start work on v2.0 while maintaining v1.0. Branches help resolve this situation
Tagging/Labeling
Another thing source code control systems do is make snapshots of the source code at a particular point in time. These are called labels in VSS, tags in subversion, etc. By creating these on a regular basis and linking them to some substantial milestone in your project it then becomes possible to determine what exactly has changed in your code between releases. This can be important for auditors but also in tracking down the source/scope of an issue. VSS also gets a fail here because VSS only versions the files, not directories. This means it is impossible to re-create a previous version of the system if you rename/move/delete files or directories in the repository (something that happens a lot if you refactor). Good source code control systems like Subversion do just this.
I suggest using SVN, because:
Source control gives you excellent history. You can see where what changes have been made, thus providing a great way to see what's changed over time (even better if you fill out the submit summary each time)
To the developer, it provides an excellent fallback if something goes horribly wrong. You can revert changes to a file back to any point in its history, so you can try out that mod you wanted to make, and if it doesn't work, roll it right back easily.
It provides a central repository that is much easier to back up than running around to different developers' computers.
It allows you to branch a project off in a different direction - useful for specializations and customizations.
It enables more than one developer to work together on the same project, and the same source, by letting you merge and otherwise manipulate changes to one central copy.
I suggest NOT using VSS - see this page for reasons:
http://www.highprogrammer.com/alan/windev/sourcesafe.html for more reasons.
If the current process is copying a folder and giving it a date, isn't that so that you get some sort of development history, so isn't that basically a simple form of source control?
So to answer any criticisms about source control, you're already doing it. Now you just need to point out the weaknesses in the current system and suggest a better one.
Why do you need to re-invent the wheel when people have really thought about a lot of the complex scenarios which can occur during development and developed the tools which let them handle them.
What you're currently doing is very fragile and will fall over if any sort of complex scenario comes up, at which point you'll have to expend a lot of energy working out how to do something that the tools already do. VSS is better than what you're doing, but doesn't have the very useful conventions that SVN, git or mercurial has which allows multiple projects to live together in a well organised manner - I'm talking branches, tags and merging, both of which are fragile and basically a nightmare under vss.
SVN does have plugins for visual studio. Some are free. But I find that tortoise-svn just eclipses anything else. The only benefit I find with a plugin is that new files get added to svn automatically.
So, weaknesses of your current system:
If you have to make a change to a file, you are likely to overwrite or be overwritten by the other dev's changes. You may not even notice this.
If you have to remember which files you've changed to copy them over some 'master' copy, you're likely to miss one at some point.
Good luck ever finding any documentation about when you made a change and why.
How could you ever build a stable automated build system on your current system? Cruise control and hudson work really well, you're hobbling yourself
VSS doesn't group changes to multiple files together very well. Everything modern does this extremely well and with atomic consistency.
VSS branch and merge support is awful. When we used it we ended up bracketing every change with comments in source code and manually copying code around rather than relying on VSS merge.
It's going to be very hard, near impossible in your current system, to have some version of the code in live maintenance and some other, later version, in heavy development. Think about what's needed to keep two projects in sync like this, you'll need a good tool. SVN can do it, git can do it really well.
That might be enough to go on with, can do more.
Having some version control system helps in any, many cases:
Single developer, single branch
The most basic task that each version control system has to perform perfectly if it wants to call itself version control is to be able to go back to specified version of a project. If you made mess of things, you can got to previous version. You can examine some previous version to check how it was done then (for example how it was before refactoring, or before removing some code/file).
Version control systems take much less disk space compared to simply saving backup copies with specified date, because they use deltaification (storing only differences from previous version) and compression. Usually backup systems are means to store last N versions of a project, sometimes with N=1 (only previous version) while version control systems (VCS) store all the history of a project. Knowing Murphy a while after deleting Nth last version you would realize that was the version you want to examine.
Additionally going back to some last version is easy and automated. You can also examine how single file looked like at some past version, and you can get differences (in diff format) between current state and some past version. You can also tag (or 'label') versions, so you can refer to past version not only by date, or by being nth version from current one, but also by symbolic name, for example v1.2 or v1.2-rc0.
With version control system you can examine history to remind you why (and how) some piece of code (some part of a given file) arrived at current state. Most VCS allow to examine line-wise history of a file, i.e. annotating each line of a file when it was changed, in what commit, and by whom (the command is named annotate, blame or praise depending on VCS). In some VCS you can search history for a version (revision) which introduced given fragment of code (e.g. called 'pickaxe search' in Git, one of VCS).
For this feature to be really useful you have to maintain some discipline: you should describe each new version (each new revision / each new commit) writing down why the change was made. Such description (commit message) is very useful, but it doesn't have natural place in backup system.
This feature of course is even more useful if you are not the only developer...
Using version control system allows for alternate way to find bugs in the code, namely by searching history to find version which introduced bug: bisectiong history. When you find revision which introduced bug, you would have limited (in best case: very limited) area to search for bug, because bug has to be in the difference betwen last working version and first version with a bug. Also you would have description of a change (a commit message) to remind you what you wanted to do. This feature is also called sometimes diff debugging. Modern version control systems (VCS) have support for automated (or semi-automated) searching the history by bisecting it (dividing history in half, finding which part contains bug, repeat until single responsible version is found), in the form of bisect (or similar) command.
For this feature to be really useful you have to maintain some discipline: you should commit (save changes / put given state in version control system to remember) single change, dealing with only one feature, with only small difference from the previous version; i.e. commit often.
Most version control systems offer various hooks which allow for example for automated testing, or automated building of a product... or simply reminding you that you do not follow coding standard (coding guidelines).
Single developer, multiple branches
Version control systems allow to create multiple alternate parallel lines of development, called branches (or streams, or views). Common case is having development branches, i.e. having separate branch for unstable development (to test new features), separate branch for stable (main, trunk) version which is (or should be) current working version, and one on more separate maintenance (fixup) branches.
Having maintenance branches allow you to do bugfixes and generate service packs / minor version with corrections to some released version, without need to worry about interference from the new development. Later you can merge maintenace branch into stable, or pick bigfix from maintenance branch into stable and development branches (if further/other development didn't fix bug independently).
Modern VCS (here modern means that both branching and merging branches is easy) allow to go a bit further, i.e. generate separate branch for working on a separate feature (so called topic branches). This allow you to switch between working one one feature to working on other feature (and not only switch from eveloping new feature to working on urgent requested bugfix).
If you are developing your product based on source of some other (usually third party) product, you really should use vendor branches to be able to easy integrate new version of a product from vendor with the changes you made. Admittedly this is no longer purely "single developer" case.
Multiple developers
Using version control systems brings even further advantages if there are more than one developer working on the same project. VCS allow for concurent (parallel) development without worrying that somebody would overwrite your changes, or does not take your changes into account. Of course using version control system is no substitute for communication.
All of the above features are even more important in the multiple-developer case: examining who generated given change, who last changed the code (aka. who broke the build), finding a bug in code not written only by you.
Simple: If the code is not in source safe, it doesn't exist
Subversion is free and better than VSS but VSS is definitely better then nothing.
Before you say anything, find out why your company is not using source control.
Once you know why, it is easy to come up with scenarios where source control can help.
Long discussion on why you should absolutely have source control:
Is Version Control necessary for a small development group (1-2 programmers)?
My comments from that thread:
You always, always want to have some
sort of Source Control even if you are
working on a project by yourself.
Having a history of changes is vital
to being able to see the state of a
codebase at any given time. There are
a variety of reasons for looking back
in a project history which range from
just being able to rollback a bad
change to providing support for an old
release when the customer just wants a
patch to fix a bug rather than
upgrading to a newer version of the
software.
Not having some sort of source control
is pure insanity.
As far as VSS goes - it's certainly better than nothing. It's definitely not the best source control and it's very dated, but the fact it that it continues to do the job for an awful lot of companies out there.
If your boss is determined to stick with Microsoft tools, go for Team Foundation Server instead of VSS. It's a much better system than VSS and it has nice features like integrated bug tracking.
Take it from me, VSS blows. It's basic file storage w/ history. Anything is better than VSS and VSS is better than nothing :)
So, can you guys tell me why
developers MUST use source control?
It provides one method for an entire
team to use; everybody operates under
the same 'ground rules'.
Changes are
orderly vs. chaotic, saving
development time.
The ability to track
changes promotes accountability and
makes it easier to find the right
persom to solve problems in the
materials maintained.
A list of exact
changes made can be generated quickly
and easily, making it easier to
advise users of the information on
how it has changed from version to
version.
It is easy to 'roll back' to
an earlier version of the
information, if a serious mistake was
made during a change.
Source Control is like insurance! You hope you never need it, but are glad you have it when you do!
Why do a formal presentation?
Assuming the team size is at least two, do a real-world example: Let two (or more, the more the better) people get the code, make their changes and show what it takes to integrate all those changes using whatever non source control means you use.
Then do the same scenario using the source control.
The amount of time and pain you save by using source control will speak for itself.
Stick to the bottom line, explain how it relates to money and your boss will probably listen.
If you are only one programmer, I'd say the main argument is the reduced chance that you will waste time (and therefore money) fixing simple mistakes, trying to rollback code that turned to be the wrong idea etc.
If you are more than one programmer then the above goes twice plus it's the only sane way to be able to work together on the same codebase without wasting even more time waiting for eachother,
Visual Source safe is better than nothing but there are free options that are better in almost every respect. If your boss needs a presentation to understand why source control is essential he might not care what tool you use once he has been enlightened. That you have experience with other tools and not vss again relates to the bottom line so that might suffice.
Why shouldn't your team adopt source control?
Even as a solo developer, I use source control. In a modern software development environment, I can think of few if any reasons why you would not use source control. It is more surprising that you don't already have it. The question strikes me as something like house painters asking "Why should we adopt the use of ladders. You know, ladders don't get the house painted - brushes do."
I'm really sorry but if you actually have to argue for [the formalization of] source control in a development environment, you're in a hopeless situation. If your boss actually needs to be convinced that source control is a worthwhile endeavor, your boss is simply not suitable to be a manager of a group of software developers. In order for someone to effectively manage, they really need at the very least a basic understanding of the landscape. I can't even imagine what's going to happen when you actually need to argue for something that's worth having an argument and doing a presentation over.
Developing without source control is like driving a car without breaks. You lose the ability to do seamless concurrent development, you lose your code getting backed up in working copies, you lose the ability to do historic research via code annotations, you lose the benefit of seeing the context and comments that accompany discrete changes, you just lose, period. Using source control is so obvious and has so many benefits, it's shocking that you'd have to justify it.
At work, we use subversion, but some developers (myself included) use Git locally via the git-svn bridge. For personal work, I use Git.
Because:
It will reduce costs - Developers will have to spend less time checking an item in/out of a real VCS than their current ad-hoc approach.
It will protect the organization's intellectual property - this should be the most important consideration for any software company (other than data...). You are payed to create software - shouldn't it be accessible in its entirety?
It will provide quicker, more reliable and straightforward backup mechanisms - all VCSs have built in dumping capabilities. These tend to be more mature than a simple file copy.
It will act as a communication mechanism between developers - depending on the version control system you may use comments/labels/checkout status to determine if someone else has worked on a file, if it has been promoted to production, if it has a corresponding support ticket number etc.
It streamlines development - the ability to compare versions of files as well as the other mechanisms will be beneficial to your company period.
The main reason we use version control is consistentency.
If the projects are not consistent then problems are going to occur and code is going to be lost.
Make sure you have buy in for the rest of the team. Maybe you can test your presentation on them? Hopefully, they see the need as well.
Nice to see good practices being initiated from the bottom up. Maybe everyone will be more likely to adopt the practice if it comes from one of their own instead of some management mandate.
To avoid things like
"Hey! What happens ? It worked yesterday."
The easiest way to convince management to invest Time in a SCCS is focus on backup and archival. By utilizing something like Subversion (SVN), you can restore any project to any point in time instantly. There is no need to have someone look through backup tapes or worry about tracking multiple versions in an obtuse directory structure.
There are obviously many other advantages (i.e. 2 people working on the same file at the same time), but backups are what quickly sold my company many years ago.
Others have mentioned the specific benefits of source control elsewhere, but I wanted to explicitly address the "VSS" portion of the question.
If your boss wants to use a Microsoft tool, Team Foundation Server with Team Suite is a very nice combination. It also has other tools included, such as bug tracking, documents, and reporting capabilities, which makes a nice platform on which to later improve your process. We are quite happy with it where I work, and my coworkers have told me horror stories about VSS.
Keep TFS in mind as a response to the 'Microsoft Tools' question.
I am a novice in the world of source/version control and I have been doing as much reading as physically possible to get my head around the different techniques that people use for their own source/version control.
One thing that I have noticed is a pretty distinct break in the methods of developers into two (possibly more?) groups: one group prefers to keep their trunk in an always-stable state and performs all maintenance and future development in the branches, while others prefer to do all of their development in the trunk and keep it in a not-so-stable state.
I am curious as to what the community here at StackOverflow prefers or if you have your own methods.
Note: If it would help tailor the answers, I should note that I am a single developer (at most there would be two or three others in the same project) who works primarily in ASP.NET and SQL Server 2005
As I'm sure you've noticed from searching the web for answers on this topic, this is one of those things where the best answer is "It depends.", and as most of the responses have indicated, it's a trade-off between how easy do you want to be able to commit/merge new code vs. managing an extensive version history that you can easily roll back for support or debugging purposes.
I work for a small company, which means that at any given time, we could have 3 or 4 different versions of code on developer machines that have not yet been committed to the repository. We use TortoiseSVN for our version control system, which gives us the ability to branch/merge without too much difficulty, as well as being able to view the update log or revert our local copies to an earlier revision pretty easily.
Based on your question, I suppose we would fall under the group of developers who attempts to keep, at all times, a stable Trunk, and we branch new code and test it before merging it back into the Trunk. We also make an effort to keep "snapshots" of each version release so that, if necessary, we can easily check out an earlier version and re-build it, without incorporating any new features intended for a future release (This is also a great mechanism for tracking down bugs, as you can use earlier versions of code to help determine when a particular bug was first introduced into your code. However, one thing to be careful of is if your application references common code that is maintained separately from your version-ed code, you will need to keep track of that too!).
On the repository, it ends up looking something like this:
Trunk
v1.0.1.x Release
v1.0.2.x Release
v1.0.2.x Bug-Fix A <-- (These get merged back into Trunk, but remain on the repo)
v1.0.2.x Bug-Fix B
v1.1.1.x Release
v1.2.1.x Development <-- (This will get merged back to Trunk, and replaced by a Release folder)
v1.2.1.x New Feature A <-- (These get merged back into the Development branch)
v1.2.1.x New Feature B
When I first started at the company, our version structure was not quite as sophisticated, and in my experience, I would say that if you have any need whatsoever to keep track of earlier versions, it is will worth the effort to put something like this together (like I said earlier, it doesn't have to look exactly like this, so long as it fits your individual needs), keep it well documented so that all contributors can maintain it (the alternative is that the creator ends up "babysitting" the repo, which quickly becomes an incredible waste of time), and encourage all your developers to follow it. It may feel like a lot of effort in the beginning, but you'll appreciate it the first time you need to take advantage of it.
Good luck!
I do all my development in the trunk. I'm a single developer and don't want to deal with the hassle of branching. When my code is stable I just tag that current version. For example I'd tag version 1.0, 2.0 beta, 2.0 release candidate 1, version 2.0, etc. Branching would probably a better alternative if you’re maintaining old versions for bug fixes and support but since I don't do this I don't worry about it.
The differences may have to do with how painful merging is or isn't in a given version control system.
With git, branching and merging is practically effortless, so it's a common workflow for me to keep my master clean and do all my work in branches. Branching and merging in svn, particularly in previous versions, isn't quite so cheap and easy, so when I was using svn I tended to work directly on the trunk.
Always stable. Even if I'm a single developer -- almost especially if I'm a lone developer.
Having a broken tree to me means one less way to know what I should be doing.
Big changes go in branches, as well as stable releases, and do the smallest unit of changes possible at any given point so as to keep moving forward at a good pace.
This is the methodology which we follow:
Any stable release should be taken from the trunk. Any further work or modifications should go inside the working branch and should be merged with trunk when ready to release.
If have multiple independent developments, each group should have there on branch which they should sync with trunc periodically and merge it back to trunk when ready.
I've always used the main trunk as head of code. Generally new development code goes in there.
We branch for releases and we may branch for a "big" destabilizing experiment.
When we make bug fixes they go into in main first and then they get merged (back-ported) into the appropriate version branch if required.
If the big experiment works out it get's merged back into main.
We use tags for build numbers in the version branches and the main. That way we can get back to a specific version and build if we have to.
I'm in for the always-stable trunk. You need to be able to rebuild the latest stable version at any time...
In your case, I'd strongly recommend avoiding a lot of branching. It's really a fairly advanced process and not necessary for small projects and small teams.
Try and keep it simple to start with, I always try to have a known working build that can reproduced for testing and deployments etc. Depending on your repository you could use revision number (SVN), or just label the known working versions as they are required.
If you find you have multiple people touching the same files then you will need to consider a branching strategy, other than that for such a small dev team it will just be un-necessary overhead...(IMO)
One aspect is how long will the changes be in an unstable state.
When a change I make might affect other people, or the nightly build, then I do my work on a branch, and merge when stable.
When the changes I make won't affect other people (because it is my private code at home, rather than code at work), then I'm OK with checking in non-working intermediate states if that's what I want. Sometimes, I'll make a few checkins in a row which are not stable; that's OK for me when it is just me who is affected and the workflow will be continuous. It's if I come back in a few years time (as opposed to just a few days) and things aren't working that it gets problematic (one disadvantage of having been around as long as I have - I do have some projects that are still in development and maintenance that are old enough to vote).
I use a variant of tagging to achieve repeatable builds - so if I need to go back to a stable version for a bug-fix, I can use the tag information to do that. It is crucial to be able to get a stable version on demand.
One key distinction is how big files tend to be on average. Big files (1000 lines +) tend to have many independent changes that are trivially automatically mergeable. So the fact that someone else is actively changing a file you are about to start work on is probably uninteresting, so it is ok if the system makes that hard to discover.
So you tend to end up a VC strategy that has a lot of branches, and easy merges. New functionality is written in new branches.
If you are working with the smaller, highly-cohesive files typical of an OO design, in a language like Java, such accidental conflicts are a lot rarer. Even as an artificial example, it is pretty hard to come up with two sets of changes that can be made to a class (and corresponding JUnit test cases) that can sensibly be made in isolation and then automatically weaved back together by a text merge tool.
If you do a lot of refactoring (renaming and splitting files) then that stresses out the merge tool even more.
So you tend to be best off with a VC strategy that has an identifiable and usable stable trunk and minimal branches.
In the first approach, new functionality is written in new branches, and merged when complete. In the second, it is written in new files, and enabled when complete.
Of course, if you do the second, you definitely need strong protection from the baseline becoming unusable for any length of time (i.e. continuous integration and a strong automatically-run test suite).
Our policy when delivering a new version is to create a branch in our VCS and handle it to our QA team. When the latter gives the green light, we tag and release our product. The branch is kept to receive (only) bug fixes so that we can create technical releases. Those bug fixes are subsequently merged on the trunk.
During this time, the trunk sees the main development work, and is potentially subject to refactoring changes.
The issue is that there is a tension between the need to have a stable trunk (so that the merge of bug fixes succeed -- it usually can't if the code has been e.g. extracted to another method, or moved to another class) and the need to refactor it when introducing new features.
The policy in our place is to not do any refactoring before enough time has passed and the branch is stable enough. When this is the case, one can start doing refactoring changes on the trunk, and bug-fixes are to be manually committed on both the trunk and the branch.
But this means that developpers must wait quite some time before committing on the trunk any refactoring change, because this could break the subsequent merge from the branch to the trunk. And having to manually port bugs from the branch to the trunk is painful. It seems to me that this hampers development...
How do you handle this tension?
Thanks.
This is a real practical problem. It gets worse if you have several versions you need to support and have branched for each. Even worse still if you have a genuine R&D branch too.
My preference was to allow the main trunk to proceed at its normal rate and not to hold on because in an environment where release timings were important commercially I could never argue the case that we should allow the code to stabilise ("what, you mean you released it in an unstable state?").
The key was to make sure that the unit tests that were created for the bug fixes were transitioned across when the bug was migrated into the main branch. If your new code changes are genuinely just re-factoring then the old tests should work equally well. If you changes are such that they are no longer valid then you can't just port you fix in any case and you'll need to have someone think hard about the fix in the new code stream.
After quite a few years managing this sort of problem I concluded that you probably need 4 code streams at a minimum to provide proper support and coverage, and a collection of pretty rigorous processes to manage code across them. It's a bit like the problem of being able to draw any map in 4 colours.
I never found any really good literature on this subject. It will inevitably be linked to your release strategy and the SLAs that you sign with your customers.
Addendum: I should also mention that it was necessary to write the branch merging as specific milestones into the release schedule of the main branch. Don't under-estimate the amount of work that might be entailed in bring your branches together if you have a collection of hard-working developers doing their job implementing features.
Where I work, we create temporary, short-lived (less than day -- a few weeks) working branches for every non-trivial change (feature add or bugfix). Trunk is stable and (ideally) potentially releasable all the time; only done items get merged into it. Everything committed from trunk gets merged into the working branches every day; this can be largely automated (we use Hudson, Ant and Subversion). (This last point because it's usually better to resolve any conflicts sooner than later, of course.)
The current model we use was largely influenced by an excellent article (which I've plugged before) by Henrik Kniberg: Version Control for Multiple Agile Teams.
(In our case, we have two scrum teams working on one codebase, but I've come to think this model can be beneficial even with one team.)
There is some overhead about the extra branching and merging, but not too much, really, once you get used to it and get better with the tools (e.g. svn merge --reintegrate is handy). And no, I do not create a temp branch always, e.g. for smaller, low-risk refactorings (unrelated to the main items currently under work) that can easily be completed with one commit to trunk.
We also maintain an older release branch in which critical bugs are fixed from time to time. Admittedly, there may be manual (sometimes tedious) merging work if some particular part of code has evolved in trunk significantly compared to the branch. (This hopefully becomes less of an issue as we move towards continually releasing increments from trunk (internally), and letting marketing & product management decide when they want to do an external release.)
I'm not sure if this answers your question directly, or if you can apply this in your environment (with the separate QA team and all) - but at least I can say that the tension you describe does not exist for us and we are free to refactor whenever. Good luck!
Maybe Git (or other DVCS) are better at handling merges to updated code thanks to the fact that they (really) manage changes rather than just compare files... As Joel says :
With distributed version control, merges are easy and work fine. So you can actually have a stable branch and a development branch, or create long-lived branches for your QA team where they test things before deployment, or you can create short-lived branches to try out new ideas and see how they work.
Not tried yet, though...
Where I work, we keep with the refactoring in the main branch. If the merges get tricky, they just have to be dealt with on an ad-hoc basis, they're all do-able, but occasionally take a bit of time.
Maybe our problem comes from the fact that we have branches that must have quite a long life (up to 18 months), and there are many fixes that have to be done against them.
Making sure that we only branch from extremely stable code would probably help, but will not be so easy... :(
I think the tension can be handled by adding following ingredients to your development process:
Continuous integration
Automated functional tests (I presume you already count with unit tests)
Automated delivery
With continuous integration, every commit implies a build where all unit tests get executed and you are alarmed if anything goes wrong. You start working more with head and you are less prone to branching the code base.
With automated functional tests, you are able to test your application at the click of the button. Generally, since these tests take more time, these are run nightly.
With this, the classic role of versioning starts to lose the importance. You do not make your decision on when to release based on the version and its maturity, it’s more of the business decision. If you have implemented unit and functional testing and your team is submitting tested code, head should always in state that can be released. Bugs are continuously discovered and fixed and release delivered but this is not any more cyclical process, it’s the continuous one.
You will probably have two types of detractors, since this implies changing some long rooted practices. First, the paradigm shift of continuous delivery seems counter-intuitive to managers. “Aren’t we risking to ship a major bug?” If you take a look at Linux or Windows distros, this is exactly what they are doing: pushing releases towards customers. And since you count with suite of automated tests, dangers are further diminished.
Next, QA team or department. (Some would argue that the problem is their existence in itself!) They will generally be aversive towards automating tests. It means learning new and sometimes complicated tool. Here, the best is to preach by doing it. Our development team started working on continuous integrations and in the same time writing the suite of functional tests with Selenium. When QA team saw the tool in action, it was difficult to oppose its implementation.
Finally, the thurth is that the process I described is not as simple as addig 3 ingredinents to your development process. It implies a deep change to the way you develop software.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
How often should I commit changes to source control ? After every small feature, or only for large features ?
I'm working on a project and have a long-term feature to implement. Currently, I'm committing after every chunk of work, i.e. every sub-feature implemented and bug fixed. I even commit after I've added a new chunk of tests for some feature after discovering a bug.
However, I'm concerned about this pattern. In a productive day of work I might make 10 commits. Given that I'm using Subversion, these commits affect the whole repository, so I wonder if it indeed is a good practice to make so many ?
Anytime I complete a "full thought" of code that compiles and runs I check-in. This usually ends up being anywhere between 15-60 minutes. Sometimes it could be longer, but I always try to checkin if I have a lot of code changes that I wouldn't want to rewrite in case of failure. I also usually make sure my code compiles and I check-in at the end of the work day before I go home.
I wouldn't worry about making "too many" commits/check-ins. It really sucks when you have to rewrite something, and it's nice to be able to rollback in small increments just in case.
When you say you are concerned that your "commits affect the whole repository" --- are you referring to the fact that the whole repository's revision number increases? I don't know how many bits Subversion uses to store it, but I'm pretty sure you're not going to run out of revision numbers! Many commits are not a problem. You can commit ten times as often as the guy next door and you won't increase your carbon footprint at all.
A single function or method should be named for what it does, and if the name is too long, it is doing too much. I try to apply the same rule to check-ins: the check-in comment should describe exactly what the change accomplishes, and if the comment is too long, I'm probably changing too much at once.
I like this small article from Jeff Atwood: Check In Early, Check In Often
I personally commit every logical group of code that is finished/stable/compiles and try not to leave the day without committing what I did that day.
If you are making major changes and are concerned about affecting others working on the code, you can create a new branch, and then merge back into the trunk after your changes are complete.
If your version control comment is longer than one or two sentences, you probably aren't committing often enough.
I follow the open-source mantra (paraphrased) - commit early, commit often.
Basically whenever I think I've added useful functionality (however small) without introducing problems for other team members.
This commit-often strategy is particularly useful in continuous integration environments as it allows integration testing against other development efforts, giving early detection of problems.
I commit everytime I'm done with a task. That usually takes 30 mins to 1 hr.
Don't commit code that doesn't actually work. Don't use your repository as a backup solution.
Instead, back up your incomplete code locally in an automated way. Time Machine takes care of me, and there are plenty of free programs for other platforms.
The rule of thumb, that I use, is check-in when the group of files being checked-in can be covered by a single check-in comment.
This is generally to ensure that check-ins are atomic and that the comments can be easily digested by other developers.
It is especially true when your changes affect a configuration file (such as a spring context file or a struts config file) that has application wide scope. If you make several 'groups' of changes before checking in, their impact overlaps in the configuration file, causing the 2 groups to become merged with each other.
I don't think you should worry so much about how often. The important thing here is what, when and why. Saying that you have to commit every 3 hours or every 24 hours really makes no sense. Commit when you have something to commit, don't if you don't.
Here's an extract from my recommended best practices for version control:
[...] If you are doing many changes to a project at the same time, split them up into logical parts and commit them in multiple sessions. This makes it much easier to track the history of individual changes, which will save you a lot of time when trying to find and fix bugs later on. For example, if you are implementing feature A, B and C and fixing bug 1, 2 and 3, that should result in a total of at least six commits, one for each feature and one for each bug. If you are working on a big feature or doing extensive refactoring, consider splitting your work up into even smaller parts, and make a commit after each part is completed. Also, when implementing independent changes to multiple logical modules, commit changes to each module separately, even if they are part of a bigger change.
Ideally, you should never leave your office with uncommitted changes on your hard drive. If you are working on projects where changes will affect other people, consider using a branch to implement your changes and merge them back into the trunk when you are done. When committing changes to libraries or projects that other projects—and thus, other people—depend on, make sure you don’t break their builds by committing code that won’t compile. However, having code that doesn’t compile is not an excuse to avoid committing. Use branches instead. [...]
Your current pattern makes sense. Keep in mind how you use this source control: what if you have to rollback, or if you want to do a diff? The chunks you describe seem like exactly the right differential in those cases: the diff will show you exactly what changed in implementing bug #(specified in checkin log), or exactly what the new code was for implementing a feature. The rollback, similarly, will only touch one thing at a time.
I also like to commit after I finish a chunk of work, which is often several times a day. I think it's easier to see what's happening in small commits than big ones. If you're worried about too many commits, you may consider creating a branch and merging it back to the trunk when the whole feature is finished.
Here's a related blog post: Coding Horror: Check In Early, Check In Often
As others have stated, try to commit one logical chunk that is "complete" enough that it does not get in other devs' way (e.g., it builds and passes automated tests).
Each dev team / company must define what is "complete enough" for each branch. For example, you may have feature branches that require the code only to build, a Trunk that also requires code to pass automated tests, and labels indicating something has passed QA testing... or something like that.
I'm not saying that this is a good pattern to follow; I'm only pointing out that how done is "done" depends on your team's / company's policies.
I also like to check in regularly. That is every time I have a completed a step towards my goal.
This is typically every couple of hours.
My difficulty is finding someone willing and able to perform so many code reviews.
Our company policy is that we need to have a code review before we can check anything in, which makes sense, but there is not always someone in the department who has time to immediately perform a code review. Possible Solutions:
More work per check in; less checkins == less reviews.
Change the company checkin policy. If I have just done some refactoring and the unit tests all run green, maybe I can relax the rule?
Shelve the change until someone can perform the review and continue working. This can be problematic if the reviewer does not like you code and you have to redesign. Juggling different stages of a task by 'shelving' changes can become messy.
The moment you think about it.
(as long as what you check in is safe)
Depends on your source code system and what else you have in place. If you're using Git, then commit whenever you finish a step. I use SVN and I like to commit when I finish a whole feature, so, every one to five hours. If I were using CVS I'd do the same.
I agree with several of the responses: do not check in code that will not compile; use a personal branch or repository if your concern is having a "backup" of the code or its changes; check in when logical units are complete.
One other thing that I would add is that depending on your environment, the check-in rate may vary with time. For example, early in a project checking in after each functional piece of a component is complete makes sense for both safety and having a revision history (I am thinking of cases where earlier bits get refactored as later ones are being developed). Later in the project, on the other hand, entirely complete functionality becomes more important, especially during integration development/testing. A half-integration or half-fix does not help anyone.
As for checking in after each bug fix: unless the fix is trivial, absolutely! Nothing is more of a pain than finding that one check in contained three fixes and one of them needs to be rolled back. More often than not it seems that in that situation the developer fixed three bugs in one area and unwinding which change goes to which bug fix is a nightmare.
I like to commit changes every 30-60 minutes, as long as it compiles cleanly and there are no regressions in unit tests.
Well, you could have your own branch to which you can commit as often as you like, and when you are done with your feature, you could merge it to the main trunk.
On the frequency of Commits, I think of it this way, how much pain would it be to me if my hard disk crashed and I hadn't committed something - the quantum of this something for me is about 2 hours of work.
Of course, I never commit something that doesn't compile.
At least once a day.
I don't have a specific time limit per commit, I tend to commit once a test has passed and I'm happy with the code. I wouldn;t commit code that does not compile or is otherwise in a state that I would not feel good about reverting to in case of failure
You have to balance the compromise between safety and recoverability on the one hand and ease of change management for the entire project on the other.
The best scheme that I've used has had two answers to that question.
We used 2 completely separate repositories : one was the project wide repository and the other was our own personal repository (we were using rcs at the time).
We would check into our personal repository very regularly, pretty much each time you saved your open files. As such the personal repository was basically a big, long ranging, undo buffer.
Once we had a chunk of code that would compile, tested ok and was accepted as being ready for general use it was checked into the project repository.
Unfortunately this system relied on the use of different VCS technologies to be workable. I've not found any satisfactory method of achieving the same results while using two of VCS of the same type (eg. two subversion repositories)
However, I have had acceptable results by creating "personal" development branches in a subversion repository - checking into the branch regularly and then merging into the trunk upon completion.
If you're working on a branch which won't be released, a commit is always safe.
However, if you are sharing it with other developers, committing non-working code is likely to be a bit annoying (particularly if it's in an important place). Normally I only commit code which is effectively "working" - not that it's been fully tested, but that I've ascertained that it does actually compile and not fail immediately.
If you're using an integrated bug tracker, it may be helpful to do separate commits if you've fixed two bugs, so that the commit log can go against the right bugs. But then again, sometimes one code change fixes two bugs, so then you just have to choose which one to put it against (unless your system allows one commit to be associated with multiple bugs)
I still believe in the phrase 'commit often, commit early'. I prefer decentralized VCS like Mercurial and there's no problem to commit several things and push it upstream later.
This is really a common question, but the real question is: Can you commit unfinished code?
Whenever you finish some code that works and won't screw anyone else up if they get it in an update.
And please make sure you comment properly.