HTML 5.... learning and posting.... will be updated regularly

Soon..:)

Perforce Case Sensitivity issue on Windows

Perforce has got a rather strange case sensitivity issue when working with case insensitive file systems like the NTFS.

I look like an idiot if i do not mention what Perforce aka P4 is....

It is a revision (or version) control system. It is used to manage file versions. The clients or the users work in their local workspaces and submit changes in a changelist.

A single file can be checked out by multiple users and when it is being submitted, perforce will try to merge your changes with the changes done by others, if there are any.

You get the latest by clicking on get latest revision.

Everything is cool up to now but there is a problem!!

Problem: Suppose, we have a file named xyz in perforce and we renamed it to Xyz for some reason. (Don't assume that this happens very rarely.... no that is not the case in real.... think about linux os where xyz is a different file from Xyz and lot of development has been happening on linux machines.)

Consider that we got the latest version (before changing the case of the xyz file)and we have xyz file in our local development environment.

Now someone changed the xyz to Xyz which is perfectly legal and you tried to get the latest version (assuming you are working on a case insensitive file system like Windows.)

You will find that the latest version of the file remains to be xyz inspite of the case change.

Because Windows uses a case-insensitive file system, references to files that differ only by case are ignored. In order to get the Perforce Server to change the case of a file on a Windows Server, the file must first be deleted and then re-added to Perforce using the correct case. Additionally, the internal Perforce "have list" references to the old case name must be eliminated by removing the file from case-insensitive workspaces and then re-syncing the file using the correct case.

Windows:

Changing xyz to Xyz

1. Delete the existing file

   p4 delete xyz
   p4 submit
   

2. Recreate the file in your local file system with the correct case. Then, use the p4 sync command to re-create the file in your workspace using the correct case.

   p4 sync Xyz#3
   

3. Remove the internal "have list" reference. The p4 flush command (sync -k, in recent versions) removes the have list reference without removing the file from your workspace.

   p4 flush Xyz#none
   

4. Re-add the file in the correct case. As with the sync command, the p4 add command uses the case of the file argument provided at the command line, so it is important to provide the correct case.

   p4 add Xyz
   p4 submit
   

all users who use workspaces on case-insenstive file systems (such as Windows NTFS or MacOS X HFS) must remove the old file from their workspace and then re-sync the renamed file with the correct case to replace it in their workspace.

1. p4 sync xyz#none
   
2. p4 sync Xyz#head

Unix:

On Unix, simply integrate the file and delete the original file.

1. Use p4 integrate to change the old name to the new name.
   

   $ p4 integrate xyz Xyz

2. Delete the original name.
   

   $ p4 delete xyz

3. Submit the changes.
   

   $ p4 submit
   

and you are ready to go!

EFFECTIVE SCRUM

Scrum Meetings can be effective and ineffective at the same time.

Idea behind a Scrum meeting:

The idea is that you have a daily stand up meeting where you basically determine how the work is progressing and if divine intervention is required to keep things progressing.

The idea is to provide a transparency where anyone can see what exactly the team is up to.

The basic format of a scrum meeting is pretty simple.  Each person on the team says three things:

1. What did I do since our last meeting
2. What am I doing until our next meeting
3. What is impeding me

On the surface these seem like sensible and valuable things for each team member to talk about, but…

So often these three things end up with little information

How many times has this happened to you?

Oh God! It’s coming around to me!  What am I going to say?

I didn’t really get much done yesterday.  I was fooling with the build, then I kept getting interrupted.  Then I was answering a bunch of emails and I ended up helping someone  with that task he was working on or learning something that i have to work on.
I don’t even know what I am really planning on doing today.  I’m just going to keep working on the backlog I am working on.  I don’t want to say that though, I need to say something more important.

So what do you do?  You kinda make up something important sounding, and you mix in some of what you did do and try and make it relate to things happening in the sprint.  You prattle on about stuff that no one really cares about, because you need to say something.

This kind of thinking is contagious!!

Pretty soon you might end up with the whole team just prattling on about things that aren’t really important to anyone else or just saying something like:

"I continued to work on backlog X, I’ll continue to work on backlog X today. Nothing is blocking me."

which just does not have any important information .

A scrum report is only valuable if it is providing usable information about the progress of an iteration and helping to bring impediments that can be resolved, to light.

Add on's to the meeting (just my idea)

Commitment!

The basic idea is pretty simple.  I replace the 3 topics in a Scrum report with my sub-classed version:

1. What did I commit myself to doing yesterday and how much did i actually finish. If something is left over, why did that happen?
2. What will I commit myself to getting done today?.
3. What is blocking me in fulfilling my commitment.

Commitment is something that carries with it accountability.

The idea is that it makes you think about what you are actually reasonably going to get done in the day.  It forces you to think about priorities and schedule.  It requires you to break down your work and think ahead a bit so that you can come up with something that you can commit to.

It also tends to make sure that what gets worked on is what should be getting worked on.  You don’t get to say what you worked on yesterday, you only get to talk about what you committed to that you either did or did not get done.  This prevents team members from talking about all the other non iteration related stuff they did.

It really makes you think before you jump off down some rabbit trail if you really want to say in Scrum the next morning that you didn’t do anything you committed to.

It really makes you think first before implying you are going to get something done.  Instead of saying “I’m going to try and finish up backlog X today,” you are more likely to break down some component of backlog X and say “I will commit to getting done task A in backlog X.”

The difference here is critical, because in it lies the value.  The value is that someone listening to your report can actually get an idea of the true progress of the team and of the backlogs being worked on by the team.  If every day team member just report they are working on backlog X and backlog Y, we aren’t really learning anything about if backlog X and backlog Y are really progressing.  On the other hand, if team members are required to make a commitment about what they are going to get done on backlog X and backlog Y, we start to get a real picture of how that work is progressing.

Planning a Sprint:

I think planning a sprint is one of the major steps in Scrum.

My idea is to have a day between the end of the previous sprint and the start of the current sprint.

We should have time to look at the product backlog and come up with an "Achievable" iteration backlog. Generally, the sprints are planned for 2-4 weeks and when we don't have at least a day to plan the iteration backlog, it becomes tough for the whole team to visualize how much can be done in that time span. Sometimes the team gets overloaded without proper planning and even after extra hours of work we might not be able to reach the target (not satisfying the commitment.) which eventually will have an effect on the morale of the team and also the clients.

If we don't have a day to plan for the sprint, then, most of the times, we end up planning iteration backlog during the time when we should have been actually working on the tasks.

This reduces the time that we have for burning down the tasks.

Also, whenever a sprint is planned, there should be a task which tracks the time for deployment process.

For example, for a sprint with some major tasks burned down, we might need to give half a day for deployment at the end of the sprint to ensure that the deployment goes well without any issues. Leaving this task out of the iteration backlog or the tasks for the sprint will mean that the team has an extra 3 hours of work which is not evident in the burn down chart. So, they have to work three hours in advance. Sometimes, this can be an issue especially when you have to do a clean build and redeploy the whole thing.

To be continued..............................