Yesterday, I encountered an analysis issue that appeared to be resolvable with a simple pattern replacement technique. 

This turned out to be a bit more complex than estimated, as the pattern spanned multiple lines and I struggled to get the regex constructed to match this use case.

I finally figured it out, and although the overall problem remains unresolved (it has many layers), this particular part works well.  My error was in how I viewed use of  /s and /m as mutually exclusive; they aren’t of course, and I have made that mistake one other time over the years.   I also hadn’t set the input record separator ($/) to paragraph read mode.   I’m posting details here to document my specific usage.

Assumptions:

• A literal pattern exists that is present in multiple places in a file
• The literal pattern spans multiple lines in the file
• Literal pattern is
  • Node-path: branches/%%BRANCHES%%
  • Node-kind: dir
  • Node-action: add
• Perl is being used to read the file and current line of file is $line
• Objective is to delete all occurrences of this pattern from the file one $line at a time

Here’s how I did that:

[read the file & crawl thru the lines]

$/ = ”;

$line =~ s/^Node-path:\sbranches\/%%BRANCHES%%.*?^Node-kind:\sdir.*?^Node-action:\sadd.*?//sm;

Tags: perl, regex, tech-tips

Update: TortoiseSVN 1.6.3 is stable and works well — jbminn

A friend of mine forwarded this to me a few days ago; I filed it away under ‘refer to later’.   Later just arrived, as I saw someone tweet about a TortoiseSVN issue on Vista.

I’m relaying this here in the hope that it saves folks the hassle of figuring it out themselves.

I [installed TortoiseSVN 1.6.2] this morning, and it just failed silently, After digging out some logs etc, I found the very helpful Microsoft message "Application did not start because its side-by-side configuration was not correct"
That has to be one of the most non-enlightening error messages of all time.

I had come across that myself before with ScreenCap, and I was able to figure out that it has some mysterious connection to the .NET framework. However, my work-around was pretty ugly, and not useful in this case.

My recovery for tortoise is that I had to uninstall the new version, restart 3 times to make sure that windows forgot about it it, and then install the older (1.6.1) version.

From previous experience with this side-by-side nonsense, this seems to be Vista specific because I’ve never seen that message in an XP machine. Interestingly enough, I didn’t see a bug report on the tortoise site, but I only did a cursory look through the list.

Tags: twitter, tortoisesvn, vista

Executive Summary

To support increased responsiveness to business needs, an enterprise is considering a move to monthly site releases. 

Increased frequency of releases places additional demands upon the engineering, QA and release teams with regard to developing, maintaining, testing, and tracking multiple lines of development.  The challenge to the enterprise is how to balance the engineering team’s need for ongoing development, which is often experimental in nature and uncertain in outcome (the “what”), with those of the business whose focus is more schedule-driven, and thus highly dependent upon calendar time (the “when”).

Developed through years of consulting in the release management space, Freepository presents a clear strategy for managing these demands through utilization of source code repository branches in Subversion (SVN).

This posting explores the “how” of managing these occasionally contradictory release management objectives.

Background

Every branch in SVN is simply a copy of another line of development. This presents new opportunities in managing these lines of development, as their topological location in the repository maps directly to their branch name. This means that branch names – the actual lines of development – are visually evident.

Using these visual and topological cues, lines of development may be easily segregated in SVN. Simply creating (or copying) a new branch creates a new line of development that is immediately and unambiguously present, available, and distinct.

How are Lines of Development Managed?

In SVN, a best practice has emerged that maps to the real-world process of release management.

{svnroot}://branches
                //tags
                //trunk

The folders ‘branches, tags and trunk’ refer to the method of organizing your lines of development. In branches, you have as many different lines as is necessary to support concurrent development, such that activity in one line of development does not destabilize activity in another line (branch).

Tags are simply ways to “save” lines of development at specific points in time. Common uses of tags include labeling a line of development that is/was released. Using the tag, you may reproduce that exact set of source code at any point in the future.

The trunk is often referred to as “main-line”, as it is where the main line of development is stored for a project. Experimental work occurs in branches, when it is deemed “ready” it is merged back to trunk. When code is packaged and released, it is tagged.

A key point here is no ongoing, day-to-day development activity occurs on the trunk. This is in contrast to the current practice at many enterprises. The trunk is literally the stable line of development that is currently in production – nothing else.

At each production release, the release tag is merged to trunk. This ensures that the trunk always contains exactly & only the state of the current production site. This is an important point and bears repeating – no ongoing development occurs on the trunk. Its sole purpose is to maintain the state of production after the fact.

The use of the branches folder in SVN supports project- or initiative-based segregation of development.

Consider this example:

{svnroot}://branches/project-one
                   branches/project-two

Two lines of development are currently active – Project One and Project Two. There is no ambiguity, as each project is clearly visible in the branches section of the SVN tree. Activity in Project One is independent of activity in Project Two.

At some point, the business determines that Project Three – a new initiative – is approved and development activity is going to start. A new branch is created to support this

{svnroot}://branches/project-three

In the same namespace where Project One and Project Two are currently under development, Project Three is now present. Its line of development may begin and progress at whatever rate is necessary and appropriate, as both Projects One and Two have been doing. This technique implies that Project One, Project Two and Project Three are decoupled; no dependencies exist, and thus these lines are truly independent.

What if there are dependencies?

A practice that I have employed elsewhere extends this technique. Lines of development that consist of multiple projects, such as site features that are dependent upon others, may be grouped together in meta-projects at inception. This facilitates immediate, ongoing integration between the articles of development in the meta-project, while maintaining separation from any other level of constraint.

Meta-projects are often given code names. This allows teams to make reference to the line of development, develop in it and for it, while keeping it separate from other activity. By using code names, the teams involved have removed the artificial constraints of schedule-based development. They are free to develop, experiment and abandon work as necessary without destabilizing any other line of development.

Continuing our example, this technique is implemented in SVN like this

{svn}://branches/eureka/project-one
                           /eureka/project-two
                           /eureka/common

Such a technique allows this related development to take place in a manner that lets the business decide when to schedule the release. This may sound confusing, but consider the case where the related activity (the set of initiatives code-named eureka in the example) is so large in scope that we cannot reasonably – at inception – estimate when it will be complete.

Using code-named based branches allows us to conduct enough engineering to make this determination, again without destabilizing any other development activity. We can then make the necessary business decisions about the release, up to and including abandoning it, knowing that we won’t have to “yank it out” of a branch where others are working.

When the projects are complete and ready to be integrated, a new branch is created, into which the project branches are merged. The integration is done when the projects are ready – not before. This decouples the engineering activity from the integration constraints usually associated with schedule-driven development.

Integration branches are used to facilitate the merging of multiple projects or initiatives into a schedule-based branch that may be tracked independently, for example:

{svnroot}://branches/integration-8.1

Creation of such a branch would support a proposed release naming convention for FY08, where we are using the year number (8) scoped with major release number (1). It is clear that this technique fully supports a release name such as 8.1.1, where this would be a bug fix of major release 8.1. Subsequent releases, if necessary, could be easily made (8.1.2, 8.1.3, etc)

What does this mean?

It means that we can support multiple lines of development in non-colliding, visually apparent, and intuitively named branches. These lines may be merged when and if they are deemed ready into the current integration branch for inclusion in the next release.

When the integration branch’s articles of development pass acceptance testing, they may be labeled with a formal release tag. The release tag may then be used to identity and obtain the entire set of articles of development anytime in the future. In this respect, SVN tags are no different from CVS tags.

The key difference is that the tag is easy to produce, as it is simply a copy. Another difference is that ongoing development can be accepted on an SVN tag; though this is generally not advised, it could facilitate rapid resolution of production bugs on release night.

Summary

The Branching Strategy may be characterized as a funnel. At the top of the funnel are loosely defined, decoupled lines of development that are not fully scoped. As the lines mature, they “fall” deeper into the funnel. Nearing the bottom of the funnel, the projects are completely engineered, fully integrated with dependent projects, until ultimately they “leave” the mouth of the funnel and get merged onto the trunk.

Tags: release management, svn, subversion, branches

Today Collabnet announced an agreement to purchase SourceForge Enterprise Edition:

http://biz.yahoo.com/e/070425/lnux8-k.html

Let the consolidation war begin.

This pretty clearly indicates the difficulty that both have had in growing their enterprise customer base. And since the deal was equity only (plus a small advertising dollars commitment over 30 months), this places enormous pressure on Collabnet for a strong exit. IBM already made a purchase in this space (Rational, whose own foray into the on-demand space years ago, Catapulse, was a spectacular flameout), and is unlikely to go too far away from the foundation of that license-fees cash cow.

CA has thus far shown no interest in on-demand solutions, so they are unlikely to step in as a white knight anytime soon. In fact, just three days ago at CA World, John Swainson made mention of “Software as a Service” in the same context as “Web 2.0″, suggesting either a serious misunderstanding of SaaS, or more likely CA’s position that while interesting, SaaS (on-demand) is not in CA’s immediate game plan.

BMC might try to make a play here – and who knows, maybe even Borland. Google would have been a likely candidate, but I speculate they did consider both Collabnet & SourceForge a couple years back, but due diligence indicated they could build a better solution (the result being Google Code). Oh, and just for completeness: Microsoft? Not a chance, so long as Collabnet is involved in SVN and its relationship with the Apache Foundation remains too cozy for comfort.

I had an email exchange with a colleague who is almost as familiar with this space as me. He seemed to think that Collabnet was preparing to announce something else, perhaps another round of financing. I disagreed.

The math on the VA revenue (16K per week for 30 months) indicates this may have been an afterthought, or perhaps someone was looking for cash to cover expenses on some other initiative inside VA. It is almost immaterial with respect to the transaction, so I’m curious why it was attached to this deal.

I would be very surprised to see Collabnet raise more money. *Somebody* was diluted by those 11MM shares going to VA. If I am an investor, I’m asking these questions:

What on earth did Collabnet really buy? The brand? The technology? Customers?

Is the Collabnet brand viewed so weakly in the marketplace that they had to purchase a competing brand? Or is it an open acknowledgment that Collabnet’s technology doesn’t scale well (I’m told that almost everything ends up being a custom one-off), and that they are planning to adopt SFEE technology to replace Collabnet’s stuff?

How this is good for Collabnet is hard for me to see. But what do I know.

I was recently asked to compare Subversion (SVN) to Perforce, and explain why I would choose to implement SVN rather than Perforce as a replacement for an existing CVS installation.

A big reason not to continue looking at Perforce is its lack of support for workflow. I asked a Perforce SE very pointed questions about how to integrate it with other tools that are very common in big shops, and the resulting answers boiled down to

“…you would have to write something to do that”.

As a pure repository management scheme, Perforce is adequate. I have seen, however, very large Perforce depots exhibit performance issues across the wire, and this would be disadvantageous. Their use of client specs (nearly identical to Clearcase’s use of config specs), means that sets of versions are tied to specific view configurations, which if lost or damaged, are nearly impossible to reproduce. This can bring your ability to reproduce builds (and the releases that were promoted from them) to a halt.

Bottom line is that Subversion is a compelling replacement for CVS because

• SVN is faster & more lightweight
• SVN uses common HTTP & HTTPS transport protocol (and thus is stateless and more compact across the wire)
• SVN uses the exact same command namespace as CVS (co => co, ci => ci, add => add, etc.)
• SVN works in virtually every IDE where CVS works

This means that porting CVS-centric automation would less difficult, and would amount to an actual porting effort rather than new development.

Oh, and one more thing: SVN licenses are $0 per developer, per seat. Forever.

Tags: svn, subversion, perforce