Working Draft: New Subversion workflow

We’re moving from a private branch focus to a feature branch focus. That will help us to all keep on the same page and should accelerate our progress in getting revisions cranked out and merged into HEAD with fewer (hopefully no) conflicts.

After the next merge, we’ll create an 095dev branch in SVN. We can then have everyone tweaking this branch for final fixes instead of working on their private branches and collectively merging those into HEAD.

Therefore, the majority of personal branches should become obsolete. If you’re working on a major feature or experiment, it will still make sense to do that in your local branch however.

Let’s also keep in mind that the commit log (in installers) and version should probably be updated upon completion of every major task. Likewise, commits should be done on a feature-by-feature or bug-by-bug basis. In the event one goes awry, we’ll be able to revert that commit and carry on more easily.

This will result in some very real world benefits including fostering collaboration between everyone (no more isolated development islands) and higher quality results faster. There should be fewer conflicts, a lot less merging to trunk, and infinitely less synching of individual branches back to trunk. This will fundamentally be like everyone committing to trunk, only we’ll have a safety net to catch the inevitable breakages.

When it’s time to merge a snapshot into the main Trunk, we need to post a message in this Topic requesting it be done. Similarly, if we need to roll back a commit, we can get that done more easily with this workflow. I’m excited about it and think it’s a very positive step in the right direction.

The new SVN policy and this move to feature-based branches is great, certainly should make life easier for all involved.

How do "core" snippets, plugins & modules fit into this? Would they have their own feature-based branch? (This does not rule out snippets having their own SVN elsewhere, of course).

All core stuff should be maintained as a project in the tattoo-assets (for now) project I think. When we’re in dev mode, like now, I hope they’d make sure the installer is updated and most recent versions are bundled, like in the 095dev branch.

Quote from: PaulGregory at Nov 16, 2006, 10:34 AM

How do "core" snippets, plugins & modules fit into this? Would they have their own feature-based branch? (This does not rule out snippets having their own SVN elsewhere, of course).

They really don’t right now Paul, but this is all going to be better organized when we switch gears after 0.9.5 final is released.

I am planning and setting up the new repository structure for 1.0 right now, and there will be completely separate repositories for the core and the various add-ons. Then there will be a third repository that contains test and build scripts that will be responsible for building a distributable packages of the product (and eventually regression testing the code prior to producing the package; a step towards what is known as continuous integration). I believe I’ll be having a vendor drop repository as well, for larger third party scripts we may want to include on a regular basis with customizations (e.g. TinyMCE, mcpuk, etc). These can then be included into MODx as SVN external declarations. xPDO will also be included as an external project.

In any case, more on that soon, but this structure will allow us to include various MODx add-ons (elements) as sub-packages in our builds. We can then offer a core-only package for people like me that don’t want any of the "default" add-ons, along with a more complete package with default content and a bunch of useful snippets in it. I’m also setting it up to allow us to continue to deploy, install, and test without having to get an installation package from the build process, despite the fact that now all the directory locations and names are configurable as part of an installation package.

I’m also going to start a series of weekly lessons/topics to help those interested in really learning how SVN software can help them work smarter and more efficiently when developing MODx and/or MODx add-ons. First topic will be feature branches vs. private branches, which will lead us into a very important topic, probably the most important when learning SVN: merging.

So at this point, the "trunk" is the latest (reasonably) stable version, and the "branches/095dev" is the latest bleeding-edge for the not-faint-of-heart?

Quote from: sottwell at Nov 18, 2006, 09:34 PM

So at this point, the "trunk" is the latest (reasonably) stable version, and the "branches/095dev" is the latest bleeding-edge for the not-faint-of-heart?

In a way, yes Susan. Trunk is going to have all code reviewed before being committed for a while. But trunk is still the official code to reference and should be much more stable than any branch. The "shared" branch is just something Ryan wanted for convenience, so those working on final bug fixes could work together and immediately test each others fixes without having to merge. This is what a typical shared feature branch would be (as opposed to a personal branch); to provide a location where a group of developers working on a specific feature, goal, or set of related features can collaborate directly with having to merge from each others private individual branches. I just hope someone is taking responsibility to keep this branch in sync with trunk as necessary.

I really recommend everyone take time to read as much about SVN as they can. The documentation is a little technically dense, but thorough and with plenty of examples. SVN really can be a tool that improves your efficiency, but only if you know how to make it work for you and not against you. A lesson on branching/merging coming soon...