I trying to prioritise features for 1.1, how about looking at the
subversion development process from the point of view of not adding
*features* but adding *users*
For example:
Subversion 1.0 - woo existing CVS users
Subversion 1.1 - woo existing SourceSafe users
.. etc ..
From my point of view, I'd rather have a Subversion 1.1 sooner (eg 6
months) that has fewer features but addresses a specific user group
completely, than a Svn 1.1 later (eg 18 months)that has lots of features
but *still* doesn't enable people to migrate to it. Obviously as a
SourceSafe user (and despiser) I would like that user group to include
me, but actually I think there are some good reasons for targetting them
anyway.
I haven't included "users new to source control" above because they can
come in at any time. Examples of other user groups to consider (post
1.1) might be arch users, clearcase, people who demand the repository is
stored in a SQL database ... I don't think anyone considers any of those
to be on the critical hit list.
Now my examples are pretty arbitary, but my point is that if you only
scratch some of everyone's itches, noone will be satisfied. Obviously I
am majorly biased (see www.sourcecross.org) but apart from doing
everyone a favour from making sourcesafe unnecessary, being a viable
alternative to sourcesafe will attract a large community, especially
Windows users who are a very large body of people. (I could also spin
that a little and suggest (very <tic>) that Windows users are primarily
immature development shops that may mature in future and buy SourceCast
<g,d&r from all those mature Windows developers out there, me
included!>)
Perhaps more to the point, SourceSafe users are going to be in a mind to
switch. Clearcase users probably aren't (unless they have changed jobs
and want to set up a similar system without the licence fees), and I
don't think I need to say anything about Arch devotees on this list...
Anyway to get to the point.
I think the main SourceSafe features that Subversion 1.0 does not cover
are:
1. Locking (both exclusive and advisory)
2. Shared files (same file in two repository locations)
3. Labels (named revisions)
There are some others which I don't think are that big a deal or the
workarounds are near trivial: cloaked projects, shadow folders (use
post-commit hook), access rights (mod_svn_authz does me fine)
1. Locking
Well, you're dealing with that. Note that the lockingplan.txt when I
read seemed to focus on Exclusive locks only - we need shared/advisory
locks as well (and locks must have the user recorded against them or the
advice is not so useful)
2. Shared files
This itch is *almost* satisfied by svn:externals, but not quite. I
don't think it would be difficult to make svn:externals work
safisfactorily - just need commits to go to the right place in the right
repository.
As far as shared files vs shared directories, I actually prefer the
directory anyway.
3. Labels
This isn't a big deal for me, and I think placing a label property on
the revision is perfectly adequate. (Other people may have other ideas,
wanting to say "svn co -r SUBVERSION_1_1_0_beta1" perhaps.)
----------
Of the other features
* I18n is very important, if scary (Obviously the current users all
have no trouble with English, so the support can all be channelled
through English speaking channels - ie users@ mailing list)
* The release procedures do need tightening: we don't need things like
the 1.0.0 broken python on Windows, and the delay in getting Windows
1.0.1 out wasn't good either.
* Working towards anything that improves integrity of historical
information (I think I mean "renames"!)
* Work towards anything that makes it easier to resolve branching /
merging ("history-sensitive merges?")
I don't have voting rights, so this is best I can do to influence
people...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 1 23:08:02 2004