We’re pleased to announce an update to uberSVN ‘Chimney House’ that includes a new and improved manageAPPS page and LDAP enhancements.
uberSVN ‘Chimney House’ 3 features plenty of improvements, including:
- Improvements to uberSVN APIs and internal development of uberSVN SDK (public release coming soon!)
- New manageAPPS page allows you to see metadata attached to your APP license, such as expiry date, number of named users, and more.
- Further improvements to the way uberSVN handles LDAP and LDAPS.
- The latest Apache Subversion 1.7.5 binaries set to active by default.
- A list of bug fixes, including some fixes and alignment of the uberSVN Access Control Team Leader and uberSVN Delegated Team Admin (where uberSVN Access Control is active)
You may have already heard, but with the latest release of Chimney House, we’re splitting uberSVN’s release cycle into two distinct phases. At least a few weeks before an update is released to the entire uberSVN user base, we’ll be giving our Latest Release Channel users a sneak preview of upcoming features and functionality. These users will get to test new features and see how they fit into the ALM environment before the update becomes widely available. Interested? Check out our blog post announcing the Latest Release Channel for more info.
For the full list of bug fixes, new features and improvements in uberSVN ‘Chimney House’ Release 3, see our Release Notes.
Not yet using uberSVN? It can be downloaded for free from http://www.ubersvn.com/
Where did February go? As a resident of Massachusetts, parts of me (namely my back, shoulders and arms) are quite happy to see those weeks get crossed off the calendar. Since my last posting here, I’ve not only been shoveling snow though. Two separate Subversion Live events were held,first in San Jose and then two weeks later in London.
Both days were extremely fruitful for those of us from WANdisco that attended and I hope our attendees felt the same way. The presentations in the various tracks were well attended, very professional and well received. A great source of information exchange was the roundtable sessions at the conclusion of each day. But what I always find most useful at events like this are the less formal conversations that occur prior to a session, or during a break, or over lunch. Not surprisingly, inquiries about what our committers were looking to do with regard to enhancing Subversion merge support was the most frequent topic raised and the subsequent discussions and feedback we received was extremely valuable.
So with that information in hand, here’s what is being initially targeted:
- Better handling of renames across merges
- partially automated merges
- Faster merges – improving performance of merge operations
- Enhancements to importing to handle 3rd Party / Vendor source code
This is really just an initial list. The team is actually still quite busy at the moment working on the final aspects of Subversion 1.7. But we are also still in active discussions about other use cases that have been raised and additional ideas may still be formulated and as those become more concrete, I’ll be quite happy to write about them here.
By the way, if you are still interested in attending Subversion Live, February’s weather pattern here in the Northeastern U.S. has accommodated you! Our Boston event scheduled for early February has been rescheduled for Tuesday, March 22. The same great agenda awaits but thankfully, the snow may not. I hope to see many of you in Boston and I’d welcome the chance to listen and learn from your experience.
P.S. I really did have to shovel a lot, including my roof!
As I stated in my last entry, there are many rich sources of feedback captured from the Subversion community. The most obvious source of data is the Subversion project’s issue tracker, which contains a lot of the issues that will drive future updates to Subversion. But there is a wealth of other data to look at to find what may be hindering users of Subversion. The Subversion mailing lists and community sites can be particularly helpful in spotting recent trends, frustrations or simply common questions that continue to arise.
But one immediate source to focus our attention on is a couple of feedback sessions that were held about a year ago and hosted by Hyrum Wright and C. Michael Pilato. The most interesting comment came from Mike’s session:
* Improved branching and merging: Everybody loves merge tracking
and tree conflicts. That is, when they don't hate it.
Subversion should be smarter, and *must* learn to gracefully deal
Needless to say, we are already targeting better ways to handle merges across renames but it never hurts to see that reiterated in the summary of a feedback session such as this.
With respect to merge tracking in general, there are already a well known set of requirements that were captured by the project prior to the improvements delivered in Subversion 1.5. These are a good reference point to start from but they do reflect the state of the project essentially at 1.4 and we want to update the use cases and capture relevant new use cases. And while merging is a primary target for continued improvement, it is not the sole focus of this scoping exercise. By no means are we limiting our attention to just this one topic.
We will continue to review both customer feedback and also the more specific issues captured in the issue tracker as we compile a prioritized list of targeted improvements. Beyond all of this data, I’m working with developers that have been involved in the project for years and their experience and instincts may prove to be as valuable source of ideas as any.
More to come…
As many reading this may already be aware, WANdisco has announced our intentions to focus our efforts towards continued enhancements to Subversion’s support for branching and merging. As our committers can see the end in sight for their efforts on Subversion 1.7, we are beginning to decide where next to direct our energy.
There already exists a wealth of data in various locations inside and outside of the project that capture good ideas for continuing the improvements to merging in Subversion. What we are not looking to do is to come up with many more ideas on the topic. Instead, we want to review and prioritize what is already out there and then decide where we can best apply our resources for biggest benefit to the Subversion community.
The work we are doing now is to review the issues, capture the use cases and then do the hard work of applying our committers expertise towards resolving these issues. This process will very likely be incremental. Delivering new enhancements will provide benefits for many of us but it also allows for a new feedback loop to show us what remains to be done and where the most benefits lie for the next set of efforts. What we won’t be doing is trying to do something grandiose that could result in elongated development cycles and delayed delivery of some solutions.
The work has really just begun. We’re now rolling up our sleeves and diving into the work. It should be fun!
I am planning to blog regularly about the process – your feedback is always welcome.