Tuesday, February 22, 2011

Even More Mercurial: sub-repos

Even More Mercurial: sub-repos



Even More Mercurial: sub-repos

More Mercurial Reading: Shared Repositories

I did some playing with Hg last night and found the basics to be easy enough. But, we're really gonna need a central repository with many projects running at once -- not something that Hg is really meant to support well. So below are some links to review.

First of course is the Hg guide itself
Man, this is deep stuff.

Here's some more also

"As an alternative, you can use hg-app http://hg.python-works.com it's hgwebdir replacement written entirely in pylons.

  • has it's own middleware to handle mercurial protocol request each request can be logged and authenticated + threaded performance unlikely to hgweb
  • full permissions per project read/write/admin access even on mercurial request
  • mako templates let's you cusmotize look and feel of application.
  • diffs annotations and source code all colored by pygments.
  • mercurial branch graph and yui-flot powered graphs
  • admin interface for performing user/permission managments as well as repository managment.
  • Additional settings for mercurial web, (hooks editable from admin panel !) also manage paths, archive, remote messages
  • backup scripts can do backup of whole app and send it over scp to desired location
  • setup project descriptions and info inside built in db for easy, non file-system operations
  • Full search text on repository codes
  • added cache with invalidation on push/repo managment for high performance and always upto date data.
  • rss / atom feeds, gravatar support
  • based on pylons 1.0 / sqlalchemy 0.6 "



Monday, February 21, 2011

A version of change

You know how you know you need to do something... you want to do that thing... you NEED to do that thing eventually... but the law or inertia just works against you? I know you've been there. Well, our IT development shop has been there for years. We've been rocking CVS as our version control system (VCS) for years (on the same server), and it's actually been OK. But some of us have seen the day of change coming for a long time now... or at least I have. The CVS is now past its prime and with new hardware we are poised to replace software as well.

Our shop often works on small projects and our developers have to work with just about every development technology known to man -- often in the same day. We grew up doing Java/Oracle mostly, but find ourselves living in .Net world these days. So Visual Studio integration would be a nice change for folks. Our guys and gals just want to focus on programming and do not want to deal with learning something ELSE new so a lower learning curve will initially seem more beneficial. In this vane, we currently don't  use a distributed VCS model nor we do likely need one (but, maybe there's some benefit here we're not thinking of).

Our projects range from small to medium-large in terms of code, though we often abuse CVS by sticking non-code in it. So, speed is not a HUGE issue, but I'm sure everyone would appreciate a speed up. Everyone knows we need to improve our tagging/branching/merging, so a VCS that helps us do this easily/safely and doesn't get in our way is desirable. Our company is pretty much Microsoft across the infrastructure board, but we rock the occasional Linux server. Our local backup is being augmented by the enterprise over-the-wire Microsoft solution that sends daily changes back to the HQ. So, we'll likely shift to a VCS that happily (natively?) runs on Windows.

So, tonight I've done more reading (been thinking about this for years) and determining the next CVS lilly pad is going to me more challenging than ever. It seems that all of the leading contenders have matured greatly.

Candidate 1 - SVN

Subversion seems to be adequate. We don't need distributed VCS and there are a lot of tools out there for it. Some of the disk and speed issues seem to have improved over the years, but likely are still issues. SVN likely offers the lowest learning curve for folks, but we also don't gain as much from it. Oh, and the migration from CVS seems to be mature. There do seem to be Windows native installations possible.

Candidate 2 - Hg
 Distributed VCS, decent documentation and rich tool sets. Learning curve will be steeper than SVN. Performance should be better than SVN, but not as fast as Git. Its python based and seems to be Windows native. I need to read more about CVS migration and how simple you can make using it (can you do central version management if you want to?). A little more reading from somewhat older links indicates that we will have a hard time following a centralized model with mercurial (though that may be a good thing).

The Rest - Git and Bzr
Git and Bazaar are both annoyingly compelling and mature. I'm going to ignore them for now however as I can't see anything that they do differently than what Hg does -reletive to our need.

Bzr seems like it is very flexible, but the toolset seems a little behind Git and Hg. Plus, it still seems to support Linux better than Windows given the competition developers seem to focus more on Hg and oddly Git for tool/integration outside of Linux.

Git is powerful and has some huge momentum. But the learning curve sounds like it's steepest here. That said, the existing toolset and mindshare to support them, particularly on Windows, seems to be present and not losing steam.

So, we don't have a decision yet, but I've provided some links below for more information.


Bazaar (bzr)

Subversion (svn)


Mercurial (hg)
Git (Git)

Comparisons

Instructions, Tutorials, Stories



Sunday, February 20, 2011

I've been waiting for..

James Fee called out two topics that I've been waiting for but failed to monitor. One is the maturation of an OpenLayers-eqsue, Flash-based mapping framework called OpenScales. We like building stuff in Flash and I remember being excited when I saw that OpenScales had started on the OpenLayers mailing list. I'm glad to see it achieve such maturity as an alternative to the ubiquitous OpenLayers (which also rocks).

The other topic relates to a running thought that I've had, "This SLD stuff sucks is too complex and time-consuming to produce for 90% of my needs. I wish there was a KML for styling - something that covers most of what I need but is simple to hack on." At the back of my mind I guess I was thinking about CSS for maps, or a something like a Mapserver Mapfile but for broader use.  Behold Carto. It's quite limited now as far as as the platforms its used in. But I hope similarly easy approaches (below) emerge as a wider alternative to SLD.

From the carto page, "We've been actively using and contributing to the Cascadenik project for several years, so it doesn't come as a surprise that Carto is heavily inspired by Mike's pioneering work in Cascadenik. We hope that our work on Carto will contribute to the emerging field of CSS-like map styling which includes projects like GSS and MapCSS and the GeoServers CSS Module"