problems with git svn clone on windoze using cygwin

I am back in a windoze development environment and am using subversion (svn) for source code control. I am trying to experiment with git so I thought I would try to use git in conjunction with svn. This is turning out to be quite a bit of trouble. It all depends on which version of svn you are using.

Basically version 1.7 is fine but version 1.6 gives horrendous problems. Version 1.6 is being used because the server backend is version 1.6.

Googling reveals that the git svn clone problems in 1.6 are acknowledged and reported as fixed in version 1.7. Deep sigh. The problems are due to missing components. Several people have made attempts to build or install the missing components but I have not come across any success stories yet. And all my attempts failed.

You might think why not just move to version 1.7. Well, there's a reason and it's to do with a bit of svn nastiness. It is to do with repo format and compatibility and is discussed in the svn release notes at http://subversion.apache.org/docs/release-notes/1.7.html. The notes says:

Subversion 1.7 servers use the same repository format as Subversion 1.6. Therefore, it is possible to seamlessly upgrade and downgrade between 1.6.x and 1.7.x servers without changing the format of the on-disk repositories.

People have quoted this and concluded that:

There is no need to do anything, your working copy will be upgraded, and will still be able to talk to the 1.6 server.

However, someone on stackoverflow responded with:

Note: TortoiseSVN will update the working copy format which will create problems for older clients. This is only a problem if you have an environment where multiple different clients are used to access the same working copy. E.g. if you access the working copy from TortoisSVN and from IDE (e.g. PHPStorm) that only supports 1.6 working copy format.

This is exactly the issue for me. Changing to a 1.7 command line client forces me to change all clients. So that'll be native WIN32 command line, cygwin command line and TortoiseSVN. And all because the client changes the working copy so it won't work with older clients. I reckon this is a nasty on the part of SVN.

I am getting quite desperate to move to git now since I am grappling with some merge issues that are decidedly more awkward in svn. I may have to bite the bullet and change all my svn clients to be version 1.7. I hope to add to this blog entry to report any issues when I get around to making the move.

The daily scrum - not!

More thoughts about the so-called daily scrum

Further to my moaning entitled "when is a scrum not a scrum" I have seen people moaning about a related phenomenon that is starting to be called "cargo cult scrum". Now after looking into this for a bit I have decided that my situation is not exactly "cargo cult scrum" but there are some similarities so I will start by talking about it.

The cargo cult

Cargo Cult Scrum is what happens when you adopt the practices,vocabulary, and artifacts of scrum but you don't understand why or how they work. It comes from the phrase "cargo cult", which I only came across a few years ago. Here is a brief summary culled from wikipedia, for those who haven't come across it yet.
The wikipedia article opens with:

"A cargo cult is a religious practice that has appeared in many traditional pre-industrial tribal societies in the wake of interaction with technologically advanced cultures. The cults focus on obtaining the material wealth the "cargo") of the advanced culture through magic and religious rituals and practices. Cult members believe that the wealth was intended for them by their deities and ancestors."

It talks about the behaviour of Melanesian islanders during and after WW2, living on islands occupied by the military. It says:

"With the end of the war, the military abandoned the airbases and stopped dropping cargo. In response, charismatic individuals developed cults among remote Melanesian populations that promised to bestow on their followers deliveries of food, arms, Jeeps, etc. The cult leaders explained that the cargo would be gifts from their own ancestors, or other sources, as had occurred with the outsider armies. In attempts to get cargo to fall by parachute or land in planes or ships again, islanders imitated the same practices they had seen the soldiers, sailors, and airmen use. Cult behaviors usually involved mimicking the day to day activities and dress styles of US soldiers, such as performing parade ground drills with wooden or salvaged rifles. The islanders carved headphones from wood and wore them while sitting in fabricated control towers. They waved the landing signals while standing on the runways. They lit signal fires and torches to light up runways and lighthouses."

Cargo cult scrum examples

Now I hope you understand where the phrase "cargo cult scrum" comes from and what it refers to. I am now seeing blogs appear where developers complain about it and describe it. I suppose I am just adding to that list. Here are some examples I found:

• I recently attended a meeting at a company that considers itself to be agile. It was a regular meeting that occurred every two weeks. It was not attended by a scrum team, but instead by a bunch of people from two different groups. The three questions were not used. The meeting was scheduled for, and took, 30 minutes. Yet the meeting was called a scrum. Other meetings at this company are called scrums, so much so that "scrum" has become a synonym for "meeting". This is a cargo cult. The true meaning of "daily scrum" has been lost, if it was ever apprehended in the first place.
• An example from a [paraphrased] conversation:
  Customer: Oh yes, we've been doing agile for a while.
  Coach: That's great! So you haven't had any trouble getting the Product Owner to work closely with the team?
  Customer: Well, we...uh...don't really have a Product Owner.
  Coach: Oh. Well, who keeps the Product Backlog in shape?
  Customer: Well, we...uh...don't really have a Product Backlog, per se.
  Coach: Oh. So how do you plan your sprints?
  Customer: Well, we really don't do that in a very formal way. But we do meet every morning. That's what it's all about, right?
  
• I saw a good summary by an agile coach which said:
  A "good" scrum implementation will be a wonderful experience only if you have people who want to be a part of a cross-functional team who trust and respect one another. You also need a spirit of self reflection, and a desire to always improve and serve the customer. You also have to have leadership that is there for support. If you hate being a part of a cross functional team, and just want to be left alone to code (or whatever) heads down, then any agile or lean
  methodology will be sheer torture. If you have a strong team with micro managers, then it will be sheer torture. If you have both...ouch, I feel bad for everyone there.
• Another person summed it up with:
  The problem with Scrum and daily scrums is:
  1) Organizations that are doing fine do not need to change anything
  2) Organizations that are failing want a quick fix. So they choose scrum
  3) Now they are doing a bunch of quick fixes, calling it progress, doing Cargo Cult Scrum, and making people miserable
  That's what I see in the field. Failed organizations choose scrum because they are failing, and then they fail harder with scrum but pretend they are on a path to salvation.
  

A name has yet to be invented

So, if I am not in a cargo cult scrum situation, what situation am I in? As far as I know it doesn't have a name yet. One thing it isn't is "ScrumBut", i.e. "we do scrum, but...". That's because there are no scrum practices at all.
The only reason scrum is mentioned is because the meeting is called a scrum instead of being called a meeting. Here are some of the symptoms:

• The daily meeting is called a scrum and consists of "what did you do since the last scrum, what are you doing now?" for each attendee. Everyone waits patiently and politely for the meeting to end, saying the minimum possible when it is their turn.
• The daily meeting gradually reduces in frequency until it is officially only once a week but in practice it is not even that. It is scheduled once a week but is frequently cancelled at point blank range ("we're too busy to have it").
• The meeting is attendees rather than team members. There are no teams in the sense of multiple people pulling in the same direction; rather, there are disparate solo workers that do not communicate with anyone. They're not
  anti-social, it's just that the nature of their work is isolated and communication is discouraged by the management.
• It lasts for the scheduled time, no more and no less. People are cut short if it looks like it is going to over-run. As attendees learn that it is has almost no value they learn to speak less and less to avoid the danger of overrun.
• The meeting does not talk about progress, how we are going to get there, the need to improve, remove obstacles etc. Instead it is about what time is being booked to (I worked on blah, today I will continue working on blah)..
• There is no allocation of work from the backlog; there is no backlog! There are no stories and no use-cases and no input from the business. There are no iterations, no releases, no burndown charts. Hence these things cannot be talked about in the meeting!
• People turn up late, the meeting starts late. The non-communication, lack of purpose or value and general lack
  of interest and the fact that the meeting is often cancelled at the last minute, means there is little reason to be there on time.
• They are not standups. No one stands up. Everyone is seated. The meeting typically lasts for one hour. Try standing up for that length of time. The word "scrum" is used not but they have not heard of "standups". Or if they have then they agree that one hour is a long time to be standing up! If you were to point out that standups should take around 15 minutes you will be told that with the number of attendees this is impossible. Plus it's impossible because of the time it takes for the management to say its piece.

Barf bags

Q. When is a brown bag not a brown bag?
A. When it's not held at lunchtime.

I have noticed a tendency to call training sessions "brown bags". I reckon it is part of the same tendency that causes people to say "scrum" when they mean "team meeting" (I use the word 'team' very loosely here).

First, here's what a brown bag is supposed to be according to wikipedia:

A brown bag seminar, session or lunch is generally a training or information session during a lunch break. "Brown bag" is representative of meals brought along by the attendees, or provided by the host. In the USA, those are often packed in brown paper bags. Brown bag seminars normally run an hour or two.

Brown bags are also described in Linda Rising's book "Fearless Change" as a way of introducing people to new ideas without it taking up official project time.

Now here's what they are not: compulsory sessions to disseminate information that is important for the project. You know the kind of thing: you are expected to attend and it is not held at lunchtime. It is not open the the general project but only to the people that are required to receive the information. It is supplied on a need-to-know basis, i.e. if they need you to know then they will tell you. There is a slideshow that is supposed to act as a substitute for attending if for some reason you cannot attend. I call these sessions 'barf bags'.

Building on Windoze with boost

Just recently I tried to build an app on Windoze that uses boost. I got an error at linktime to do with a missing symbol from boost. It was for system_category() in the boost system library. I eventually tracked down the cause, which is very non-obvious. It is to do with 32 bit versus 64 bit building. I am using Windoze 7, 64 bit. The problem was caused by the way I was using jam to do the boost build. The command line to use is:

bjam toolset=msvc-10.0 variant=release threading=multi link=static
--address-model=64 --build-type=complete --with-system

In particular, note that
you must say --address-model=64. the -- is very important. Some other reports of this issue on the web say that you have to say address-model=64.

Grid computing and high availability

One of the things I found out when working on a grid system is that Murphy's Law works overtime there. In fact I would go as far as to say that on a grid "even if nothing can go wrong then it will". So, for the next time, if ever, that I find myself working on a grid system, I will probably want to refer to this article about HA-OSCAR that I found in The Linux Journal.

Capturing a wiki

Trawling through my notes and ancient reminders to myself on this wet Sunday morning, I am reminded to publish a link I found in the Linux Journal. It is a very useful article on how to capture a wiki using wget.

Prettyprinting C++ code

After all these decades, there is still I need for prettyprinters. I am in shock. I was spoilt in java-land, where eclipse takes care of this for you. In C++ it's a different story.

I have to say that these days most C++ is formatted OK. Enough years have gone by that most people recognise that making the source readable to humans is important enough for it to be worth that little bit of extra effort. Sadly, not everyone is enlightened so poorly formatted C++ code is still being written today. C++ IDEs that take care of this issue are not universally used. IDEs themselves are still a bit of an issue since there is no multi-platform IDE that most C++ people can agree on. Eclipse CDT isn't there yet and in my opinion is several years away. So the question is, what to do?

I have given up on GNU indent. It was meant for C anyway rather than C++ so it can easily get confused and do the wrong thing when presented with C++. The GNU project had an appeal a few years ago for a new maintainer, but no-one stepped up to the plate. The project languishes in obscurity now. However, there is a new program called astyle, which stands for Artistic Style. I have been using this recently and find it to be OK; not brilliant but OK. So this is what I will use for now. I think it could do with some of the options/features that GNU indent has but beggars can't be choosers.

A while ago, when I was still in java-land, I thought that the eclipse formatter plugin might be used. It certainly works very well for java. There is a blog entry about this that discusses running the eclipse plugin from the command line for C++ code.

Java: separating unit tests from integration tests

I have been going through some old notes of mine and came across a link to a very informative blog about how to keep unit tests and integration tests separate when using maven. The link is onjavahell.blogspot.com. Enjoy...

Downloading large files on Windoze

Many websites that contain large files to download warn Windoze users that under Windoze the download may get silently truncated. I have seen these warnings often but paid no attention to them because I always assumed it was only users of Internet Exploiter that were vunerable. Well I was wrong. I got nobbled by this problem today using Firefox. I was trying to download a debian DVD image at 4.4GB. It downloaded 980MB and stopped. Grr!

I thought, oh well, I will just have to use wget. And then the trouble started. I was in a corporate environment so there was a proxy. It is possible to configure wget with a proxy but you do need to know the proxy details. They can be viewed from the control panel but then you can get a nasty problem. The information is shown in a non-resizeable window (duh!). So the proxy information I was after was clipped, due to the URL being quite long. I found that to get the value in a normal resizeable window you have to look it up in the registry. The key is Computer\KEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL. Armed with this information I set the environment variable http_proxy (lowercase) to the value and ran wget. It worked like a dream.

I think I must be the only person in the world who thinks that windows with variable content must always be resizeable. As far as I can see, all GUI environments seem to encourage people to create non-resizeable windows. I think MicrosoftWindows makes more use of them than any other GUI environment though. Other GUIs sometimes copy windows so these GUIs are also increasing the number of non-resizeable windows. Deep sigh.