You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2008/03/07 16:41:24 UTC
Feature-by-feature evaluation of v1.5
As part of evaulating the readiness of v1.5 for release, I want to tease out
any real concerns about the usability of the current features that are
troubling people.
Ideally, we'll be able to get at least one or two people to conduct a very
high-level review of each significant feature. The aim is to understand and
write down the limitations of the feature from a user's point of view, ignoring
our knowledge of the project's history and how the software works. Note any
improvements that are desirable but don't block it from release. I expect most
of the concerns can be satisfied by documenting the restrictions in a positive
way, but in the extreme case of us deciding that some aspect of a feature is
currently more harmful than good we can consider disabling that aspect.
Here's a suggested list of features to look at [1]:
# Merge Tracking
# Sparse checkouts
# Copy/move-related improvements
# Interactive conflict resolution
# WebDAV transparent write-through proxy
# Cyrus SASL support for ra_svn and svnserve
# Changelist support
# Relative and peg URLs in svn:externals
# FSFS sharding
# Easier to try out experimental ra_serf DAV access module
The sort of thing I'm thinking of would be to make just a few notes about each
of the following:
- Look from both a new user's and a power user's point of view.
- Where is the feature documented, and to what extent?
- How clearly does the documentation (book, web, built-in help) state what
to expect from the feature and how to use it safely, so that the user's
expectations are set appropriately? Are the boundaries for successful use
reflected in the help, the error messages, and the general usability?
- How complete is the feature?
- Does the feature behave well enough, within its limitations, for users to
be happy with using it in its current state?
- Can we see a good upgrade path for its limitations?
- Are there any ways of using it that will likely cause problems in the
future, or that lead to results that are so nasty that we'd be better off
disabling those cases for the time being?
Could you - anyone - volunteer to do this for one of the features?
Remember, we are in the position of having a lot of good features that we're
nearly ready to release, so try not to be overly critical of what we've
created. Look only for practical things we might need to do right now to avoid
leading ourselves into trouble.
- Julian
[1] Taken from Eric's "Technology Preview" email
<http://svn.haxx.se/dev/archive-2008-02/0807.shtml> which includes some of his
concerns on some of them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature-by-feature evaluation of v1.5
Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> "Dan Christian" <dc...@google.com> writes:
>> It occurs that I know a good bit about this feature and should help
>> work on docs. Where is this kind of thing documented? Is the
>> submittion process the same as code?
>
> This would go in the release notes; post here a patch to
> https://svn.collab.net/repos/svn/trunk/www/svn_1.5_releasenotes.html and
> we'll make sure it gets incorporated.
>
> For some of these things we'll also do a line in the CHANGES file, but
> just getting it into the release notes will do for now, since the two
> will be compared to each other before the release.
Dan might also be wondering if there are svnbook contributions to be made
here, and what *that* process is. Information around submitting patches to
the book can be found on the book's homepage -- http://svnbook.red-bean.com/
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Feature-by-feature evaluation of v1.5
Posted by Karl Fogel <kf...@red-bean.com>.
"Dan Christian" <dc...@google.com> writes:
> On Fri, Mar 7, 2008 at 9:19 AM, Karl Fogel <kf...@red-bean.com> wrote:
>> # FSFS sharding
>>
>> The
>> third is an under-the-hood kind of thing, IIRC.
>
> Let me make a plug for FSFS sharding. System administrators are also
> a kind of user. A better title might be "improved large deployment
> support".
Thanks, that's a good idea. I've done it into the in-progress CHANGES
file at http://svn.red-bean.com/repos/manyhands/trunk/changes-1.5/CHANGES.
> The FSFS sharding makes repositories with millions of revision practical.
>
> I would add in the fact that transactions can now be built up on local
> disk. This helps multiple svn servers share a NFS repository for
> improved scalability.
>
> These are kind of subtle things that are probably very
> under-documented right now.
+1 (Anything else you can think of?)
> It occurs that I know a good bit about this feature and should help
> work on docs. Where is this kind of thing documented? Is the
> submittion process the same as code?
This would go in the release notes; post here a patch to
https://svn.collab.net/repos/svn/trunk/www/svn_1.5_releasenotes.html and
we'll make sure it gets incorporated.
For some of these things we'll also do a line in the CHANGES file, but
just getting it into the release notes will do for now, since the two
will be compared to each other before the release.
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature-by-feature evaluation of v1.5
Posted by Dan Christian <dc...@google.com>.
On Fri, Mar 7, 2008 at 9:19 AM, Karl Fogel <kf...@red-bean.com> wrote:
> # FSFS sharding
>
> The
> third is an under-the-hood kind of thing, IIRC.
Let me make a plug for FSFS sharding. System administrators are also
a kind of user. A better title might be "improved large deployment
support".
The FSFS sharding makes repositories with millions of revision practical.
I would add in the fact that transactions can now be built up on local
disk. This helps multiple svn servers share a NFS repository for
improved scalability.
These are kind of subtle things that are probably very
under-documented right now.
It occurs that I know a good bit about this feature and should help
work on docs. Where is this kind of thing documented? Is the
submittion process the same as code?
-Dan C
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature-by-feature evaluation of v1.5
Posted by David Glasser <gl...@davidglasser.net>.
On Fri, Mar 7, 2008 at 9:19 AM, Karl Fogel <kf...@red-bean.com> wrote:
> Julian Foad <ju...@btopenworld.com> writes:
> > Here's a suggested list of features to look at [1]:
> >
> > # Merge Tracking
> > # Sparse checkouts
>
> > # Interactive conflict resolution
> > # WebDAV transparent write-through proxy
> > # Cyrus SASL support for ra_svn and svnserve
> > # Changelist support
> > # Relative and peg URLs in svn:externals
>
> I think we can eliminate these from your list:
>
>
> # Easier to try out experimental ra_serf DAV access module
> # Copy/move-related improvements
> # FSFS sharding
>
> The first is about ongoing serf improvements -- wherever that is in 1.5,
> that's what we release; it was never a release definer. The second is
> too vague for testers to do much with (there is a more detailed list in
> http://svn.red-bean.com/repos/manyhands/trunk/changes-1.5/CHANGES). The
> third is an under-the-hood kind of thing, IIRC.
Re copy/move improvements. This encompasses a few separate things.
One of them is the multi-target copy/move; this is pretty
straightforward and should be mentioned in the release notes as a
(minor) new capability.
The bigger question in my mind is the copy-on-update thing.
Specifically, there's a start towards this in 1.5, and the server-side
implementation works pretty well, but the wc/client side of things is
a little iffier. I think it is worth doing the "feature evaluation"
on this, specifically to decide whether or not it's in good enough
shape that it's even worth mentioning in the release notes at all, vs
just considering as a minor technical detail for CHANGES.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Feature-by-feature evaluation of v1.5
Posted by Karl Fogel <kf...@red-bean.com>.
Julian Foad <ju...@btopenworld.com> writes:
> Here's a suggested list of features to look at [1]:
>
> # Merge Tracking
> # Sparse checkouts
> # Interactive conflict resolution
> # WebDAV transparent write-through proxy
> # Cyrus SASL support for ra_svn and svnserve
> # Changelist support
> # Relative and peg URLs in svn:externals
I think we can eliminate these from your list:
# Easier to try out experimental ra_serf DAV access module
# Copy/move-related improvements
# FSFS sharding
The first is about ongoing serf improvements -- wherever that is in 1.5,
that's what we release; it was never a release definer. The second is
too vague for testers to do much with (there is a more detailed list in
http://svn.red-bean.com/repos/manyhands/trunk/changes-1.5/CHANGES). The
third is an under-the-hood kind of thing, IIRC.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org