14

A group of developers that I am working with switched from VSS to SVN about half a year ago. The transition from CheckOut-CheckIn to Update-Commit has been hard on a number of users. Now that they are no longer forced to check in their files when they are done (or more accurately, now that no one else can see that they have the file checked out and tell them to check back in in order to release the lock on the file), it has happened on more than one occasion that users have forgotten to Commit their changes until long after they were completed.

Although most users are good about Committing their changes, the issue is serious enough that the decision might be made to force users to get locks on all files in SVN before editing. I would rather not see this happen, but I am at a loss over how to improve the situation in another way. So can anyone suggest ways to do any of the following:

  1. Track what files users have edited but have not yet Committed changes for
  2. Encourage users to be more consistent with Committing changes when they are done
  3. Help finish off the user education necessary to get people used to the new version control paradigm

Out-of-the-box solutions welcome (ie: desktop program that reminds users to commit if they have not done so in a given interval, automatically get stats of user Commit rates and send warning emails if frequency drops below a certain threshold, etc).

Community
  • 1
  • 1
Yaakov Ellis
  • 40,752
  • 27
  • 129
  • 174
  • 5
    checkin or we will find developers who will checkin to replace you always works –  Feb 22 '10 at 19:25

10 Answers10

14

...users have forgotten to Commit their changes until long after they were completed.

I think this is the problem right here. How can a feature/bugfix be "completed" if it isn't checked in? Do you have an issue tracking system that records outstanding issues? Do you have a continuous integration system that runs unit tests as soon as a checkin is made?

If developers are just off doing their own thing with no accountability, then it's not surprising that you're running into problems getting everybody to cooperate. You will need some kind of oversight (project manager? team lead?) who is responsible for making sure that individual developers are cooperating with the rest of the developer team.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
  • Unfortunately, unit tests and continuous integration are still in the early stages of adoption. And even with unit tests, if the user forgot to Commit their unit tests to the test project, then the tests could still pass with them forgetting to Commit. – Yaakov Ellis Feb 22 '10 at 18:31
  • Seriously, this is the kind of thing that the development manager/lead needs to address and enforce. – Ken Liu Feb 22 '10 at 18:38
  • 1
    @Yaakov Ellis, How about not having the same person write the code and the unit tests? – Abizern Feb 22 '10 at 18:47
  • @Abizern - that is a long-term goal, but not something that can be implemented across the board very quickly – Yaakov Ellis Feb 22 '10 at 19:49
  • 3
    +1 A feature is not "completed" until it's been tested in a staging environment. If you deploy to staging directly from subversion (as you should), this fixes the forgot-to-commit problem. – Gabe Moothart Feb 23 '10 at 17:36
6

Do you use any kind of bug/feature tracking software?
You could ask them to include revision number when they tick off the completed work.

z-boss
  • 17,111
  • 12
  • 49
  • 81
  • Use FogBugz for bug tracking and home-grown software for task-tracking on new projects. – Yaakov Ellis Feb 22 '10 at 18:30
  • +1 and also configure the bug tracker to require some QA, e.g. code reviews or test reviews. It's a good idea anyway and it certainly forces people to commit! – MarkJ Dec 30 '11 at 12:27
6

If you used VSS before, you probably work in Visual Studio. AnkhSVN has a pending changes window, like the one in TFS and VSS. This toolwindow automatically shows what files are locally modified in your solution.

Using this pending change window for your changes makes it easy to work on small/logical changes and commit those changes early instead of later.

[See this screenshot of an older AnkhSVN version]
(source: collab.net)

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Bert Huijben
  • 19,525
  • 4
  • 57
  • 73
  • Somewhat similarly, in Eclipse, files with local changes are marked in the Package Explorer with a little icon indicating that file's status wrt svn. (gold cylinder = no local changes since last update, brown star = modified, blue '+' = added, etc.). If you have that view open all the time, you get used to seeing that and all-gold-cylinders meaning "Everything that I've done has been committed." – Tyler Feb 24 '10 at 00:16
5

I think the problem you have is actually lack of a contigous build system combinet with a tracking of bugs/features/changes. With a bug track system and a contigous build, the developer can claim 'complete' only after his changes made it to the automated build and a release containing the changes is built, passes build validation tests and is dropped on the release drop location. Since the only way for a change to 'make' it into a build is to check in (an possible reverse integrate the feature branch into the main branch/trunk), devs will have to check in, otherwise they'll never finish anything ever.

Remus Rusanu
  • 288,378
  • 40
  • 442
  • 569
4

Get an automated build machine (or at the very least one dedicated person doing builds), and deploy only from that machine. Then your code doesn't get deployed until you commit, and it helps ensure that nothing was left out of the repository.

Additionally, having at least a few members of a team committing early and often usually encourages others to keep up too, because the slow committer has to deal with more local merge conflicts.

John Flinchbaugh
  • 2,338
  • 1
  • 17
  • 20
2

In a small development group, I've seen a daily email sent to the group' mailing list showing a summary of the checkins from the prior day and an unofficial 'horse race' showing number of checkins, total lines, etc within the last 30 days to be helpful. Obviously you can't use number of checkins as any kind of performance metric, but it was still fun and kept source control on everyones mind. "Hey, Joe just passed me on checkins this month, oh wait, I never checked in that code yesterday".

This also has other advantages as people come in in the morning and read it over their cofee or whatever it keeps what other people are doing in developers minds. When we get into 'code freeze' and are nearing a release, we actually change the email from just a checkin summary, to include the actual 'diffs' so that every line of code gets many-eyed right away.

bdk
  • 4,769
  • 29
  • 33
1

Typically, the thing that encourages developers to commit frequently is self-preservation. When updates become difficult for them because of merge conflicts and they discover that the problem is alleviated by pushing their changes, they will commit more often.

It does sound like there is something fundamentally wrong, though. How are your developer's getting their changes into the released product without going through the VCS? You should close that back door.

William Pursell
  • 204,365
  • 48
  • 270
  • 300
  • 1
    "How are your developer's getting their changes into the released product without going through the VCS" - That is the issue. In a small number of cases code hasn't been released when it should have been. I am attempting to figure out a way to close that back door right now. – Yaakov Ellis Feb 22 '10 at 19:50
1

Automate your builds and deployments, and make it part of the process that nothing is "done" until it is tested on the test server

Matt Briggs
  • 41,224
  • 16
  • 95
  • 126
0

Read the commit log and ask people about their status and when they will have checked in their changes. Committing whole pieces is better than committing as if it was a way to 'save'.

How can a developer finish something and forget to check it in? Is the delivery process such that the user runs a build from the developer's own machine?

Christian
  • 9,417
  • 1
  • 39
  • 48
  • Reading the commit log works in theory, but is hard to do manually. Some type of automated method would be preferred. The delivery process process may involve a third user Updating from SVN and then uploading changes. Unfortunately, there is still a ways to go with Unit Testing, so no way to automatically check that all changes have been included (and even if there was, same problem of forgetting to Commit new unit tests would exist as well). – Yaakov Ellis Feb 22 '10 at 18:29
0

A decent bug/feature tracker will allow you to add a bug number when you commit your changes. For example, if I'm running Redmine, I can commit with "Fixes #323" somewhere in my subversion commit message and it will automatically close bug/task 323. Its setup is very easy; you just have to tell Redmine where the repository is, which is asks for anyway.

This way you can see which changes have been committed against each bug, and bugs without a commit will be open (unless manually closed). You can assign bugs to milestones, and before the release of a milestone, review the commits against the bug.

Trac also does this, as do many others.

Montag451
  • 1,168
  • 3
  • 14
  • 30
Jim T
  • 12,336
  • 5
  • 29
  • 43
  • The problem here isnt so much associating the Commits with tasks. It is to make sure that people are committing everything. – Yaakov Ellis Feb 23 '10 at 19:00
  • 1
    I think the idea is that you say "Did you fix that bug?" and if the developer says "Yeah but I didn't commit it yet" then it's considered "not fixed yet" – Tyler Feb 24 '10 at 00:18
  • 1
    The association is intended to ensure that people commit everything. The idea being that if you grab a task from a website, the easiest way of saying that task is done is to add "Fixes #323" on the commit comment, which kind of ensures there's a commit. – Jim T Feb 25 '10 at 11:45