On the issue of 3rd parties implementing a front end for the feature, I
could be wrong, but I would think that releasing the support for the feature
in an actual version release would actually provide more motivation for the
developers of the client side utilities to start implementing and seriously
testing the client support for that particular feature. If I was developing
such client utilities, I'd probably put any features not currently supported
by the release version of the server product lower in my priority list than
those that are currently supported in the server.
So, early release of the feature, I would think would probably drive earlier
support for that feature on the client side.
I'd be interested to hear what those folks that actually do develop client
utilities think about this assertion.
-----Original Message-----
From: Chris Seawood [mailto:cls@seawood.org]
Sent: Tuesday, March 13, 2007 10:20 AM
To: Mark Phippard
Cc: Roy Franz; Wesley J. Landaker; users@subversion.tigris.org; Hyrum K.
Wright
Subject: Re: Subversion 1.5
Mark Phippard wrote:
> On 3/9/07, *Roy Franz* <roy.lists@gmail.com
> <mailto:roy.lists@gmail.com>> wrote:
>
> On 3/9/07, Mark Phippard <markphip@gmail.com
> <mailto:markphip@gmail.com>> wrote:
> > On 3/9/07, Wesley J. Landaker <wjl@icecavern.net
> <mailto:wjl@icecavern.net>> wrote:
> > > 1.5 would be *well* worth it just for SASL and sparse directory
> support
> > > IMHO. Merge tracking will be an excellent improvment, but I'm
> much less
> > > interested in getting that quickly. =)
> >
> > Everyone should understand the sparse directories are mainly going
> to be
> > included at the API level. I do not think there is going to be
> any command
> > line level UI to create them (in the proposed timeframe). In
theory,
> > various GUI tools or other consumers of the API could do something
> with them
> > though.
> >
> > I think if some UI did create a working copy that used this
> feature, command
> > line options like update should respect them.
>
>
> This is rather disappointing, since if there is no user interface to
> make use of this feature then it is mostly useless to the end user.
> If only APIs are provided then the
> feature is only of academic interest.
>
>
> The UI issues are complicated and have not even been started. So we can
> either not release the feature until the UI is ready, or release the API
> now and let TortoiseSVN, Subclipse etc.. have the option of building
> their UI's that use the feature today. That has the added benefit of
> getting the feature used earlier.
If the UI issues are as complicated as you say, wouldn't it take the 3rd
party GUI tools just as long, if not longer, to implement a frontend for
the API? It seems that there'd be a non-zero chance that you'd need to
tweak the API when addressing problems that arise when implementing such
a complicated UI. And presumably, tweaking the API would mean that
you'd have to rev a now released API, which seems like something you'd
want to avoid if possible. Given those assumptions, I'd think you'd
want to hold off on releasing a partial feature that has near zero
end-user impact since even with the partial feature, we're still stuck
with hacking .svn/entries at this point.
Btw, what sort of timeframe are you talking about for implementing the
commandline UI? If 1.5 released now, would the commandline UI be ready
for 1.5.1 or are you talking more of a 1.6+ timetrame?
- cls
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 16 13:59:43 2007