Subversion Joins ASF
Interesting little throwaway titbit from this item
Ironically, I think Subversion is mainly used for corporate projects these
days, while open-source ones increasingly move to distributed VCSes (Bazaar,
Re: Subversion Joins ASF
I spend most of my day writing Java code, doing code reviews and
investigating problems in releases. We mainly us CVS for source
control, with a bit of SVN. To move off these, I would want most of
this wish list filled:
- Tight integration with my IDE (Eclipse). Both SVN and CVS have
excellent integration, but the new kids on the block are still
- Tight integtation with the Windows file system (e.g. Tortoise CVS
and Tortoise SVN)
- Compare of non-text files - EAR, WAR, JAR, ZIP with drill-down. No
VCS seems to do this well.
- Compare of binary proprietary formats - e.g. Excel, Word. A good
VCS should support plugins to handle new formats. CVS is hopeless, and
I think SVN is no better. And I've not seen any newer VCS trumpetting
- Decent reporting - e.g. "What has been changed since our last
- Importing of history when migrating from CVS or whatever.
- Good integration with ANT and Maven 2 so that we can script
checkout, build and tag operations.
- Easy to learn. For developers, a VCS is a very necessary tool, but
we don't want to spend hours learning how to use it. It should be
intuitive to an experienced user of any other VCS.
CVS is no longer being developed, so I expect that we will need to
move sometime soon. But VCS systems are just a tool - and it is
difficult to invent a better hammer. Let's hope the market stabilises.
What are others considering for an upgrade from CVS?
Re: Subversion Joins ASF
In message <7da29954-5263-4b52-9ed5-
firstname.lastname@example.org>, Ron McNulty wrote:
> - Tight integration with my IDE (Eclipse).
I think you’ll find that Eclipse has plugins for integrating with all VCSes
worth their salt. Use this thing called a web search engine to find them,
> - Compare of non-text files - EAR, WAR, JAR, ZIP with drill-down. No
> VCS seems to do this well.
Why do you need to? Those are the products of builds, not sources. It’s the
sources you need to manage.
> - Compare of binary proprietary formats ...
If you need this, you’re doing it wrong.
> - Decent reporting - e.g. "What has been changed since our last
That’s just a simple diff between the head commit and the commit tagged
> - Importing of history when migrating from CVS or whatever.
They all do that.
> - Good integration with ANT and Maven 2 so that we can script
> checkout, build and tag operations.
If those build tools can’t deal with simple shell commands to do these
things, it’s their fault.
> - Easy to learn. For developers, a VCS is a very necessary tool, but
> we don't want to spend hours learning how to use it. It should be
> intuitive to an experienced user of any other VCS.
That depends very much on your corporate culture. The change in mindset
involved in moving from a centralized to a decentralized model can be beyond
the abilities of some, but others might just take to it like a duck to
water. Also management can see it as a loss of control.
Of course you realize that, even with your existing centralized setup, some
of your staff might already be using decentralized interfaces without you
knowing, e.g. git-cvs, git-svn.
|All times are GMT. The time now is 06:39 AM.|
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.