A Glass case of Thoughts

Preparing your repository for branching and merging can turn into a headache when you do it for the first time. This is a small .. may be obvious .. note to everybody who can get some help

My setup

• SVN Server hosted on linux
• Tortoise SVN as client being used from windows

If you perform following checks before getting into the process of branching and merging, you are going to save a lot of time and efforts trying to figure out errors messages and causes

1. Make sure your SVN Server version is above 1.5. If not, UPGRADE. In my case it was 1.4.2 and I upgraded it to 1.6.* from Collabnet
2. Make sure your SVN Repository version is upgraded. You can find that out by using following commands
   

   cd /path/to/repo/reponame
   cd db
   cat format
   

   
   i.e. changing to repo/directory/db and looking at contents of format file. For 1.4.*, format file showed 2, which should be 4 for it to be a 1.6.* repository. I had to upgrade the repository version by using
   

   svnadmin upgrade path/to/repo/reponame
   

3. Make sure your SVN Client is equipped to handle features offered by the upgraded SVN Server. I just downloaded version of tortoise svn made for 1.6 version

After these checks, you can choose the model you want to opt for your process and get started.

In my case, I chose mainline development happening in trunk, creating branches after each phase release. Every-time a bug is fixed in a branch, its committed to its corresponding branch. Then from trunk, using TortoiseSVN’s “reintegrate a branch” option, I choose repository URL of branch and follow through steps to finish the merge. It works wonders !

Related posts

• How to make SVN remember password
• What to do : When your SVN client saves a wrong password
• linux how to: replicate svn repository
• linux: create svn repository
• SVN : Utility commands

Numbers related to processes in project management:

Knowledge areas
What:
A way to organize processes by their own virtue
How many: 9

C

Comminication

Q

Quality

T

Time

C

Cost

H

Human Resources

I

Integration

R

Risk

P

Procurement

S

Scope

Process groups
What:
A way to organize processes by the action they are used in
How many: 5

1. Initiating
2. Planning
3. Executing
4. Monitoring & Controlling
5. Closure

Processes: 44
– Yet to remember

Purpose:

1. Utility to report issues/ tasks
2. Convey status of each task on list unambiguously

Contribution to planning:

1. Plan releases
2. Manage product versions

Configuration:

1. Projects: Projects should be clearly defined in the system to avoid any confusions regarding the context of the reported issue/ given task
2. Versions: At least three versions should always be considered in roadmap
3. Status: Enough status codes should be defined to convey the actions being taken without having to spend time on co-ordination for this task.

Status transition process:
A process that has always worked for me in all the projects till date

Reported

Issue has been reported, waiting to be assigned

Assigned

Issue has been assigned to a team member

Accepted

Issue has been reproduced by the assignee and has accepted to resolve it. At this point of time, the developer should specify the due date for delivery of fix.

NotAccepted

Issue could not be reproduced by the assignee and requires more information. Issue notes should specify the data required

Testing

Issue has been fixed and is being unit tested by developer

Requires Testing

Developer has completely tested the issue and requires a tester to test it

Resolved

Tester has tested the issue successfully. If tester does not approve it to be tested, the status should be changed back to assigned with details in issue notes.

Closed

The issue has been successfully tested in both test as well as deployed version. The issue is determined to be eliminated. There should be only one person who should be responsible for closing issues – preferrable a tester appointed by client.

Re-opened

An old closed issue has been detected in later version and has been reopened waiting to be assigned.

Tools used:
JIRA
FLYSPRAY

JIRA Analogy
Help: Ernie’s inputs

JIRA gives us capability to create multiple projects hence helping us to draw boundaries for tasks. Apart from that it also allows us to create Components for a project – another level of abstraction – could be towards modules in a project.

By default JIRA provides following status codes

• Open
• In progress
• Cannot reproduce
• Won’t fix
• Resolved
• Closed
• Re-opened

Process mapping:
We have two options to map our process to JIRA

1. Create a completely customized list of status codes for our process – simple and best
2. Map the default status codes of JIRA to process status codes

Reported		JIRA allows to create a task and not assign it to anyone. That option was turned off, but it is now enabled. So, a task which has been created and not assigned would fit this
Assigned		In JIRA, this is a task which is “open” and assigned to someone
Accepted		In JIRA, this would be a task that is “in progress” (click “start progress” under “available workflow actions”).
Not Accepted		When an issue is marked as “resolved” in JIRA, the person who is resolving it has to specify what the resolution is. Some of the choices here include “Won’t fix” and “Cannot reproduce”. That seems to cover “not accepted” pretty well.
Testing, Requires testing, Resolved		In JIRA terminology, marking an issue “Resolved” generally means that the coding is done and the developer is satisfied with it – at which point it would move on for testing. We could also add a status “testing” to the default statuses to accomplish the requirement.
Closed		As is in JIRA
Re-opened		As is in JIRA